https://wiki.tei-c.org/api.php?action=feedcontributions&feedformat=atom&user=Peter+Boot 2026-04-21T13:05:01Z User contributions MediaWiki 1.32.0 https://wiki.tei-c.org/index.php?title=Getting_Started&diff=5629 2009-03-29T21:14:19Z

<p>Peter Boot: </p> <hr /> <div>[[Category:Recommended Practice]]<br /> This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]]. Here is the provisional result: [http://tei.oucs.ox.ac.uk/GettingStarted/html/index.html http://tei.oucs.ox.ac.uk/GettingStarted/html/index.html]. Here are comments on the drafts: [[Getting Started Comments]]<br /> <br /> ==Introduction (Peter) ==<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ===What this document does, and what it doesn't===<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ==Should you use TEI? (James)==<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ==Technical background (David)==<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ==Overall structure of a TEI text (Peter)==<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ==The rationale of declarative markup (Arianna) ==<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ==Choosing and installing an editor==<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ==Load, modify, validate a complete ready-made document (Peter) ==<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ==Running stylesheets (Peter) ==<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ==Getting this to work on sample of own text==<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ==Schema's (Laurent)==<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ==Where to go from here==<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ==Glossary==<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ==Literature==<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started_Comments&diff=5628 2009-03-29T21:13:55Z

<p>Peter Boot: New page: Comments on the drafts written up to the Lyon meeting:</p> <hr /> <div>Comments on the drafts written up to the Lyon meeting:</div>

Peter Boot https://wiki.tei-c.org/index.php?title=About_Getting_Started&diff=5627 2009-03-29T21:13:18Z

<p>Peter Boot: </p> <hr /> <div>[[Category:Recommended Practice]]<br /> Here we document, for the time being, arguments and decisions about the contents, the audience, the writing style etc. of the 'Getting started' document. Here is the outline of the Getting Started Document: [[Getting Started]]. Here are comments on the drafts: [[Getting Started Comments]]<br /> <br /> ==Purpose==<br /> * Someone that has read this document and that has gone through the steps the document describes (installing and using an editor, etc.) should be able to create, modify and validate a simple TEI document. He/she should be able to create an HTML representation of that document. He/she should also be able to assess the hurdles he/she faces in using TEI in his/her project and to decide on a proper course of action (e.g.: undertake project on his/her own, seek help in local institution or in wider TEI community, seek formal training). <br /> ==Audience== <br /> * The document targets an academic (postgraduate, PhD, researcher, professor) that wants to start understanding and using the TEI: e.g. a graduate student who wants to make an edition of a book he/she is writing a thesis on. The document assumes someone working on his/her own, willing to learn something new, ready to work hard and to try various solutions. We assume someone that is reasonably comfortable using computers, but has no experience in programming and no previous knowledge of XML or HTML. <br /> * Secondarily, we should also include in our target audience people who are not themselves scholars but who are, or will be, working as encoders with a project. These may be undergraduates, editorial assistants, etc. We can assume that they are equally motivated with the academic readers, but they may not be familiar with the technical vocabulary of textual studies, bibliography, etc.<br /> <br /> ==Software==<br /> * Because we want to help people getting started, there is no way we can avoid talking about specific software programs. We must be specific. Neither can we avoid talking about commercial software, as oXygen is the environment of choice for so many people using TEI. <br /> * We should avoid the editors that are favoured by programmers and other technically oriented persons, such as emacs or vi. We want to minimise the learning effort expended on tools; what people should learn here is the TEI.<br /> * What we also want to avoid are expensive editors. We're writing this for people that are getting started. They are probably unwilling to invest a large amount of money.<br /> * If possible, we should avoid command-line tools. In fact, we want to recommend an editor that comes with validation and facilities for running a transformation. <br /> * We should try to discuss editors that work on the three major platforms. <br /> * The upshot of this is, for me: we discuss oXygen (inexpensive, works everywhere, very powerful, but not open source) and the XML Copy editor (Open source, works on Windows and Linux, reasonably powerful). Arianna suggests including jEdit.<br /> * All of these either come with an xslt processor (oXygen and XML Copy editor) or have a plugin for the purpose (jEdit).<br /> * The 'official' document will be based on oXygen. Other versions will be placed on the TEI wiki. <br /> <br /> ==Schema's and ODD==<br /> * From a logical point of view, for any project that uses the TEI, ODD is the starting point. ODD helps you make a schema and the schema helps you create and validate xml documents. From an educational point of view, however, it makes more sense to start with an XML transcription of a document, and introduce the schema after that. A schema, let alone ODD, makes no sense to someone who is not familiar with xml documents. Therefore, the idea of making a schema that fits your documents, and the way of making such a schema, is introduced only after the reader is familiar with modifying and validating XML documents. <br /> <br /> ==Contents==<br /> * As to TEI elements, this document stresses elementary things such as div, p, lg, l, hi, etc. As a TEI document must have a header, it will mention the header and provide some instruction for filling it, but it will focus on quickly attaining results, rather that on the administrative side of things.<br /> * As to schema's: throughout the getting started document, we use RELAX NG. We mention DTD's and W3C Schema's as an option, without going into their syntax. We explain RELAX using the XML syntax, and mention the existence of the compact syntax.<br /> * As to XSLT: the document will explain some of the concepts of XSLT (templates, XPATH, ...), and it will encourage readers to make some small changes to a toy stylesheet. It will discuss the stylesheets provided by the TEI and guide readers in making a simple customisation. It will not try to provide further instruction in XSLT.<br /> <br /> ==Style==<br /> * We should try to be as clear and simple as possible. In a way, council members are not the best persons to write this document, as they may be too familiar with the technicalities to avoid terminology not immediately clear to beginners. We should be prepared to have this document reviewed by people less experienced in TEI and XML than we are. <br /> * Obviously, divisions of this document authored by non-native speakers of English should be reviewed by native speakers.<br /> <br /> ==Media use==<br /> * The document should include lots of screen shots. It may also contains links to video's of screen capture.<br /> <br /> ==Technical setup==<br /> * The document is stored in Subversion in SourceForge. The relevant folder is [https://tei.svn.sourceforge.net/svnroot/tei/trunk/Documents/GettingStarted https://tei.svn.sourceforge.net/svnroot/tei/trunk/Documents/GettingStarted]. There is a main document (gettingstarted.xml) that includes the separate sections using XInclude. This makes it easier for multiple people to work on the document simultaneously. Editors without SourceForge access can mail updated sections to Peter, who will then add them in SoureForge.<br /> * Sebastian Rahtz has set up a cron job to generate [http://tei.oucs.ox.ac.uk/GettingStarted/html/ a current HTML view] of the source files (assuming they have been committed to the SourceForge repository) <br /> * all sections carry xml:id-attributes. As we should assume new sections will be added or sections will be moved around, top-level sections are identified using two-letter abbreviations. <br /> * names of elements, attributes, etc are tagged using the appropriate elements from the documentation tagset (&amp;lt;att&gt;, &amp;lt;gi&gt;, &amp;lt;ident&gt;)<br /> * images are stored in a subfolder 'images' of the main Subversion folder<br /> * abbreviations and other technical terms refer to entries in the Glossary using &amp;lt;ref&gt; elements<br /> * examples will be numbered by the stylesheet. We provide them with id attributes with values 'xaabbb', where 'x' is a literal, 'aa' is the section id and 'bbb' is an acronym for the example, unique in that section of the document. Refer to the examples using &amp;lt;ptr&gt;</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=5008 2009-01-07T20:21:47Z

<p>Peter Boot: </p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]]. Here is the provisional result: [http://tei.oucs.ox.ac.uk/GettingStarted/html/index.html http://tei.oucs.ox.ac.uk/GettingStarted/html/index.html]<br /> <br /> ==Introduction (Peter) ==<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ===What this document does, and what it doesn't===<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ==Should you use TEI? (James)==<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ==Technical background (David)==<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ==Overall structure of a TEI text (Peter)==<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ==The rationale of declarative markup (Arianna) ==<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ==Choosing and installing an editor==<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ==Load, modify, validate a complete ready-made document (Peter) ==<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ==Running stylesheets (Peter) ==<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ==Getting this to work on sample of own text==<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ==Schema's (Laurent)==<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ==Where to go from here==<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ==Glossary==<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ==Literature==<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=SIG:Correspondence&diff=4725 2008-10-26T18:42:34Z

<p>Peter Boot: /* Current Projects */</p> <hr /> <div>== TEI Special Interest Group for Correspondence (TEI Correspondence SIG) ==<br /> <br /> <br /> === News ===<br /> <br /> The SIG will initially meet at the 2008 Members Meeting at King's College in London on 8th November 2008.<br /> <br /> === Introduction ===<br /> The TEI Special Interest Group on Correspondence seeks to bring together scholars interested in creating digital scholarly editions of correspondence. The goal of the SIG will be to discuss and develop sample tagsets (including suggesting additions/modifications to the TEI Guidelines) for varying forms of correspondence as well as to create tutorials and best practice models.<br /> <br /> Because the initiative for this SIG emerged from editorial work with 19th century letters, the organizers of this SIG have focused on these types of materials. However, we want this SIG to be more encompassing, embracing varying types of historical and literary correspondence including epistles, telegrams, postcards, etc.<br /> <br /> The common feature of these sorts of text is a generally formalized physical appearance (e.g., an envelope for letters) and structure of content (i.e. address field, special formulas for opener and closer). [http://www.tei-c.org/Activities/Projects/da03.xml DALF] was one of the best documented projects in this area developing specific DTDs for those needs in P4: this may be a starting point for further work in P5.<br /> <br /> Initial topics for the SIG Correspondence may include:<br /> * the handling of the envelope and postal addresses<br /> * the formal description of correspondence as a written dialogue between an author and an addressee<br /> * correspondence-specific bibliographical data within the metadata section<br /> <br /> === Activities ===<br /> <br /> The SIG runs a mailing list, which you can join by visiting http://listserv.brown.edu/tei-corresp-sig.html .<br /> <br /> === Results of current discussions ===<br /> <br /> [In the future, there will be minutes or summaries of current discussions here.]<br /> <br /> === Useful links ===<br /> <br /> ==== Current Projects ====<br /> <br /> Please add your projects alphabetically with link and (if possible) a short description!<br /> * Digital Archive of Letters by Flemish authors and composers from the 19th &amp; 20th century, [http://www.kantl.be/ctb/project/dalf/ DALF]<br /> * Gundolf-Elli. Correspondence between Friedrich Gundolf and Elisabeth Salomon (George-Kreis). Project at the German Literature Archive. There is no website, yet. For more information use the mailing list.<br /> * eMunch. Edvard Munch's written material: Complete letters, diaries and writings, [http://www.emunch.no/index_eng.htm eMunch] (temporary, will be improved)<br /> * Online edition of the correspondence concerning the journal 'Van Nu en Straks'. Project at the Centre for Scholarly Editing and Document Studies (KANTL-CTB, Ghent) and Ghent University (Belgium). This project is part of the broader DALF-project (see above). So far, there is no real website yet, [http://www.kantl.be/ctb/project/2007/nustraks.htm/ only some information in Dutch] For more information, use the mailing list.<br /> * Weber, C.M.v.: Complete letters, diaries, writings and compositions, [http://www.weber-gesamtausgabe.de/ Carl-Maria-von-Weber-Gesamtausgabe] (at the moment german only)<br /> * Vincent van Gogh, The letters [http://www.huygensinstituut.knaw.nl/index.php?option=com_content&amp;task=view&amp;id=37&amp;Itemid=45 Vincent van Gogh, The letters] (limited info only). A full edition of all the extant correspondence of Vincent van Gogh (900 letters). The edition will include a full transcription (in Dutch and French), a translation into English, a full facsimile, extensive annotation and about 2000 illustrations. The edition will be available on the web, and, somewhat abridged, in book form. See also [http://www3.vangoghmuseum.nl/vgm/index.jsp?page=162741&amp;lang=en more info]<br /> <br /> ==== Completed Projects ====<br /> <br /> <br /> [[Category:SIG|Correspondence]]</div>

Peter Boot https://wiki.tei-c.org/index.php?title=SIG:Correspondence&diff=4724 2008-10-26T18:41:32Z

<p>Peter Boot: /* Current Projects */</p> <hr /> <div>== TEI Special Interest Group for Correspondence (TEI Correspondence SIG) ==<br /> <br /> <br /> === News ===<br /> <br /> The SIG will initially meet at the 2008 Members Meeting at King's College in London on 8th November 2008.<br /> <br /> === Introduction ===<br /> The TEI Special Interest Group on Correspondence seeks to bring together scholars interested in creating digital scholarly editions of correspondence. The goal of the SIG will be to discuss and develop sample tagsets (including suggesting additions/modifications to the TEI Guidelines) for varying forms of correspondence as well as to create tutorials and best practice models.<br /> <br /> Because the initiative for this SIG emerged from editorial work with 19th century letters, the organizers of this SIG have focused on these types of materials. However, we want this SIG to be more encompassing, embracing varying types of historical and literary correspondence including epistles, telegrams, postcards, etc.<br /> <br /> The common feature of these sorts of text is a generally formalized physical appearance (e.g., an envelope for letters) and structure of content (i.e. address field, special formulas for opener and closer). [http://www.tei-c.org/Activities/Projects/da03.xml DALF] was one of the best documented projects in this area developing specific DTDs for those needs in P4: this may be a starting point for further work in P5.<br /> <br /> Initial topics for the SIG Correspondence may include:<br /> * the handling of the envelope and postal addresses<br /> * the formal description of correspondence as a written dialogue between an author and an addressee<br /> * correspondence-specific bibliographical data within the metadata section<br /> <br /> === Activities ===<br /> <br /> The SIG runs a mailing list, which you can join by visiting http://listserv.brown.edu/tei-corresp-sig.html .<br /> <br /> === Results of current discussions ===<br /> <br /> [In the future, there will be minutes or summaries of current discussions here.]<br /> <br /> === Useful links ===<br /> <br /> ==== Current Projects ====<br /> <br /> Please add your projects alphabetically with link and (if possible) a short description!<br /> * Digital Archive of Letters by Flemish authors and composers from the 19th &amp; 20th century, [http://www.kantl.be/ctb/project/dalf/ DALF]<br /> * Gundolf-Elli. Correspondence between Friedrich Gundolf and Elisabeth Salomon (George-Kreis). Project at the German Literature Archive. There is no website, yet. For more information use the mailing list.<br /> * eMunch. Edvard Munch's written material: Complete letters, diaries and writings, [http://www.emunch.no/index_eng.htm eMunch] (temporary, will be improved)<br /> * Online edition of the correspondence concerning the journal 'Van Nu en Straks'. Project at the Centre for Scholarly Editing and Document Studies (KANTL-CTB, Ghent) and Ghent University (Belgium). This project is part of the broader DALF-project (see above). So far, there is no real website yet, [http://www.kantl.be/ctb/project/2007/nustraks.htm/ only some information in Dutch] For more information, use the mailing list.<br /> * Weber, C.M.v.: Complete letters, diaries, writings and compositions, [http://www.weber-gesamtausgabe.de/ Carl-Maria-von-Weber-Gesamtausgabe] (at the moment german only)<br /> * Vincent van Gogh, The letters [http://www.huygensinstituut.knaw.nl/index.php?option=com_content&amp;task=view&amp;id=37&amp;Itemid=45 Vincent van Gogh, The letters] (limited info only). A full edition of all the extant correspondence of Vincent van Gogh. The edition will include a full transcription (in Dutch and French), a translation into English, a full facsimile, extensive annotation and about 2000 illustrations. The edition will be available on the web, and, somewhat abridged, in book form. See also [http://www3.vangoghmuseum.nl/vgm/index.jsp?page=162741&amp;lang=en more info]<br /> <br /> ==== Completed Projects ====<br /> <br /> <br /> [[Category:SIG|Correspondence]]</div>

Peter Boot https://wiki.tei-c.org/index.php?title=SIG:Correspondence&diff=4723 2008-10-26T18:36:57Z

<p>Peter Boot: /* Current Projects */</p> <hr /> <div>== TEI Special Interest Group for Correspondence (TEI Correspondence SIG) ==<br /> <br /> <br /> === News ===<br /> <br /> The SIG will initially meet at the 2008 Members Meeting at King's College in London on 8th November 2008.<br /> <br /> === Introduction ===<br /> The TEI Special Interest Group on Correspondence seeks to bring together scholars interested in creating digital scholarly editions of correspondence. The goal of the SIG will be to discuss and develop sample tagsets (including suggesting additions/modifications to the TEI Guidelines) for varying forms of correspondence as well as to create tutorials and best practice models.<br /> <br /> Because the initiative for this SIG emerged from editorial work with 19th century letters, the organizers of this SIG have focused on these types of materials. However, we want this SIG to be more encompassing, embracing varying types of historical and literary correspondence including epistles, telegrams, postcards, etc.<br /> <br /> The common feature of these sorts of text is a generally formalized physical appearance (e.g., an envelope for letters) and structure of content (i.e. address field, special formulas for opener and closer). [http://www.tei-c.org/Activities/Projects/da03.xml DALF] was one of the best documented projects in this area developing specific DTDs for those needs in P4: this may be a starting point for further work in P5.<br /> <br /> Initial topics for the SIG Correspondence may include:<br /> * the handling of the envelope and postal addresses<br /> * the formal description of correspondence as a written dialogue between an author and an addressee<br /> * correspondence-specific bibliographical data within the metadata section<br /> <br /> === Activities ===<br /> <br /> The SIG runs a mailing list, which you can join by visiting http://listserv.brown.edu/tei-corresp-sig.html .<br /> <br /> === Results of current discussions ===<br /> <br /> [In the future, there will be minutes or summaries of current discussions here.]<br /> <br /> === Useful links ===<br /> <br /> ==== Current Projects ====<br /> <br /> Please add your projects alphabetically with link and (if possible) a short description!<br /> * Digital Archive of Letters by Flemish authors and composers from the 19th &amp; 20th century, [http://www.kantl.be/ctb/project/dalf/ DALF]<br /> * Gundolf-Elli. Correspondence between Friedrich Gundolf and Elisabeth Salomon (George-Kreis). Project at the German Literature Archive. There is no website, yet. For more information use the mailing list.<br /> * eMunch. Edvard Munch's written material: Complete letters, diaries and writings, [http://www.emunch.no/index_eng.htm eMunch] (temporary, will be improved)<br /> * Online edition of the correspondence concerning the journal 'Van Nu en Straks'. Project at the Centre for Scholarly Editing and Document Studies (KANTL-CTB, Ghent) and Ghent University (Belgium). This project is part of the broader DALF-project (see above). So far, there is no real website yet, [http://www.kantl.be/ctb/project/2007/nustraks.htm/ only some information in Dutch] For more information, use the mailing list.<br /> * Weber, C.M.v.: Complete letters, diaries, writings and compositions, [http://www.weber-gesamtausgabe.de/ Carl-Maria-von-Weber-Gesamtausgabe] (at the moment german only)<br /> * Vincent van Gogh, The letters [http://www.huygensinstituut.knaw.nl/index.php?option=com_content&amp;task=view&amp;id=37&amp;Itemid=45 Vincent van Gogh, The letters] (limited info only)<br /> <br /> ==== Completed Projects ====<br /> <br /> <br /> [[Category:SIG|Correspondence]]</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4705 2008-10-07T11:32:46Z

<p>Peter Boot: /* Running stylesheets */</p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]]. Here is the provisional result: [http://peterboot.nl/tei/gs.html http://peterboot.nl/tei/gs.html]<br /> <br /> ==Introduction (Peter) ==<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ===What this document does, and what it doesn't===<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ==Should you use TEI? (James)==<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ==Technical background (David)==<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ==Overall structure of a TEI text (Peter)==<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ==The rationale of declarative markup (Arianna) ==<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ==Choosing and installing an editor==<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ==Load, modify, validate a complete ready-made document (Peter) ==<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ==Running stylesheets (Peter) ==<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ==Getting this to work on sample of own text==<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ==Schema's (Laurent)==<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ==Where to go from here==<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ==Glossary==<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ==Literature==<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4704 2008-10-07T11:31:53Z

<p>Peter Boot: /* Load, modify, validate a complete ready-made document */</p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]]. Here is the provisional result: [http://peterboot.nl/tei/gs.html http://peterboot.nl/tei/gs.html]<br /> <br /> ==Introduction (Peter) ==<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ===What this document does, and what it doesn't===<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ==Should you use TEI? (James)==<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ==Technical background (David)==<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ==Overall structure of a TEI text (Peter)==<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ==The rationale of declarative markup (Arianna) ==<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ==Choosing and installing an editor==<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ==Load, modify, validate a complete ready-made document (Peter) ==<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ==Running stylesheets ==<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ==Getting this to work on sample of own text==<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ==Schema's (Laurent)==<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ==Where to go from here==<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ==Glossary==<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ==Literature==<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4703 2008-10-07T11:31:37Z

<p>Peter Boot: /* Overall structure of a TEI text */</p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]]. Here is the provisional result: [http://peterboot.nl/tei/gs.html http://peterboot.nl/tei/gs.html]<br /> <br /> ==Introduction (Peter) ==<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ===What this document does, and what it doesn't===<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ==Should you use TEI? (James)==<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ==Technical background (David)==<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ==Overall structure of a TEI text (Peter)==<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ==The rationale of declarative markup (Arianna) ==<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ==Choosing and installing an editor==<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ==Load, modify, validate a complete ready-made document==<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ==Running stylesheets ==<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ==Getting this to work on sample of own text==<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ==Schema's (Laurent)==<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ==Where to go from here==<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ==Glossary==<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ==Literature==<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4702 2008-10-07T11:31:20Z

<p>Peter Boot: /* The rationale of declarative markup */</p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]]. Here is the provisional result: [http://peterboot.nl/tei/gs.html http://peterboot.nl/tei/gs.html]<br /> <br /> ==Introduction (Peter) ==<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ===What this document does, and what it doesn't===<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ==Should you use TEI? (James)==<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ==Technical background (David)==<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ==Overall structure of a TEI text==<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ==The rationale of declarative markup (Arianna) ==<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ==Choosing and installing an editor==<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ==Load, modify, validate a complete ready-made document==<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ==Running stylesheets ==<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ==Getting this to work on sample of own text==<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ==Schema's (Laurent)==<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ==Where to go from here==<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ==Glossary==<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ==Literature==<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Council&diff=4701 2008-10-07T11:03:43Z

<p>Peter Boot: /* Issues for next Telco - Oct 2008 */</p> <hr /> <div>== Council Telco - 21 August 2008 ==<br /> Minutes of the last meeting: http://www.tei-c.org/Activities/Council/Meetings/tcm39.xml<br /> == Issues for next Telco - Oct 2008 ==<br /> * update on SF bugs and features (Oxford)<br /> <br /> * report to TEI MM<br /> <br /> * naming releases/versions (tei vs. P5)<br /> <br /> Peter Boot: tei.full - tei.components<br /> <br /> This refers to my (PB's) question on the council list ([http://lists.village.virginia.edu/pipermail/tei-council/2008/009971.html http://lists.village.virginia.edu/pipermail/tei-council/2008/009971.html]) about identification of releases and the following discussions. The difference between the two packages (tei.full - tei.components ) on SF has been clarified. Sebastian has added version numbers to generated schema’s. <br /> <br /> Issues that remain<br /> <br /> - do we use the SF news mechanism (a project where the latest news item dates from a year ago doesn't seem very dynamic)<br /> <br /> - Roma shows a version number of the software, not of the TEI release that is being used<br /> <br /> <br /> * update on SIGs + responsabilities<br /> <br /> * placement of Schematron rules in ODD<br /> http://lists.village.virginia.edu/pipermail/tei-council/2008/010033.html<br /> <br /> Note to be produced by SR<br /> <br /> * update on '&quot;getting started&quot;', see https://USER@tei.svn.sourceforge.net/svnroot/tei/trunk/Documents/GettingStarted (replacing 'USER' with your SourceForge username) and [[Getting Started]]<br /> <br /> Looking for candidates:<br /> ** 6. Choosing and installing an editor<br /> ** 9. Getting this to work on sample of own text<br /> ** 11. Where to go from here<br /> <br /> == Issues for next F2F ==<br /> <br /> * Discussion on ODD and its evolution--[[User:Romary|Romary]] 02:34, 9 September 2008 (EDT)<br /> <br /> cf. @usage in elementSpec<br /> <br /> * should the TEI-C we produce a general purpose online service which can validate and process documents (cf. ISO work)<br /> <br /> == Highlights to be brought to the TEI MM 2008 ==<br /> <br /> <br /> == Topics (could be moved up to one F2F or Telco meeting ==<br /> <br /> * Stable reference to TEI objects<br /> <br /> [LR] In many cases, one has to map schemas and describe the mappings by reference to actual objects in the respective encoding schemes. In this context do (should) we have a mechanism to refer uniquely to TEI objects, beyond the reference to the TEI namespace (&lt;author&gt; in http://www.tei-c.org/ns/1.0), sort of TEI unique identifiers?<br /> <br /> [JC] I'd think the proper way to cite an element, class, or datatype generally is to point to its reference page. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-tree.html<br /> <br /> However, we might want to re-examine that... while the hierarchy should remain the same, deprecated elements (etc.) disappear. I have no way easy way to point to something at a particular date in time...unless maybe I point to it at a particular revision in the SVN source tree?<br /> <br /> Pointing to a location in the SVN source tree isn't necessarily very pretty but does work and is accurate:<br /> <br /> See for example an earlier version of &lt;event&gt;: http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?revision=231&amp;view=markup<br /> <br /> As a cognate example, I can point to any revision of a page in the TEI wiki at any point in its history. We should be able to do this, somehow, in the official way we are meant to cite TEI sources as changing objects in time.<br /> <br /> However, maybe an easier solution is to cite:<br /> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-event.html<br /> but on the generated reference pages like this contain a link to the appropriate place in the SVN repository? i.e.<br /> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?view=log <br /> which lists all the revisions.<br /> <br /> [AC] The only place on the website where I am ware there are some recommendations with URLs is the citation page:<br /> http://www.tei-c.org/Guidelines/access.xml<br /> <br /> This could certainly be enriched with notes on how to point to an element on the line James suggests, but in that case would the version number be enough to point to particular revisions?<br /> <br /> [DS] As an alternative to using a TEI-specific convention for citing URLs, we<br /> might want to consider adopting one or another of the standard systems<br /> for permanent identifiers, for example DOI (Digital Object Identifier).<br /> <br /> In the case of DOI, there would be some fairly minimal costs involved to<br /> register the DOIs with one of the national registries, but some more<br /> extensive costs in human time to set up a good system for mapping from<br /> our existing nomenclature to a set of DOI identifiers. (Publishers<br /> typically use DOIs to identify individual books or journal articles, but<br /> they can be more granular: every reference page in the Guidelines could<br /> have its own DOI, for example.)<br /> <br /> The advantage of doing this would be that anyone accustomed to using<br /> DOIs for citations could simply cite a DOI. So instead of the reference<br /> for &lt;name&gt; in the Guidelines<br /> <br /> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-name.html<br /> <br /> we would use something like<br /> <br /> doi:10.1111/tei-p5-doc:en:ref-name.html<br /> <br /> which would be resolved to the actual Web address by a DOI resolver.<br /> (Many journal DOIs are mostly numeric but the syntax allows more<br /> human-readable names).<br /> <br /> If we seriously want to consider an option like this, we should put out<br /> a call to the librarians/metadata gurus in our community for assistance<br /> with implementation.<br /> <br /> [PB] The latter is certainly much more elegant and resistant to change. I'd remove the '.html' at the end. HTML might be yesteryear's fashion a few years from now :-)<br /> <br /> == Misc. ==<br /> For general information concerning the council see [[TEI-Council-FAQ]]<br /> <br /> <br /> [[Category:Council]]<br /> Page and category reserved for use by TEI Council...</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4601 2008-09-16T20:28:38Z

<p>Peter Boot: /* Schema's */</p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]]. Here is the provisional result: [http://peterboot.nl/tei/gs.html http://peterboot.nl/tei/gs.html]<br /> <br /> ==Introduction (Peter) ==<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ===What this document does, and what it doesn't===<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ==Should you use TEI? (James)==<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ==Technical background (David)==<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ==Overall structure of a TEI text==<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ==The rationale of declarative markup==<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ==Choosing and installing an editor==<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ==Load, modify, validate a complete ready-made document==<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ==Running stylesheets ==<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ==Getting this to work on sample of own text==<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ==Schema's (Laurent)==<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ==Where to go from here==<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ==Glossary==<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ==Literature==<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4600 2008-09-16T20:28:21Z

<p>Peter Boot: /* Technical background */</p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]]. Here is the provisional result: [http://peterboot.nl/tei/gs.html http://peterboot.nl/tei/gs.html]<br /> <br /> ==Introduction (Peter) ==<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ===What this document does, and what it doesn't===<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ==Should you use TEI? (James)==<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ==Technical background (David)==<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ==Overall structure of a TEI text==<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ==The rationale of declarative markup==<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ==Choosing and installing an editor==<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ==Load, modify, validate a complete ready-made document==<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ==Running stylesheets ==<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ==Getting this to work on sample of own text==<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ==Schema's==<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ==Where to go from here==<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ==Glossary==<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ==Literature==<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4599 2008-09-16T20:28:08Z

<p>Peter Boot: /* Should you use TEI? */</p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]]. Here is the provisional result: [http://peterboot.nl/tei/gs.html http://peterboot.nl/tei/gs.html]<br /> <br /> ==Introduction (Peter) ==<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ===What this document does, and what it doesn't===<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ==Should you use TEI? (James)==<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ==Technical background==<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ==Overall structure of a TEI text==<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ==The rationale of declarative markup==<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ==Choosing and installing an editor==<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ==Load, modify, validate a complete ready-made document==<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ==Running stylesheets ==<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ==Getting this to work on sample of own text==<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ==Schema's==<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ==Where to go from here==<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ==Glossary==<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ==Literature==<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Council&diff=4592 2008-09-12T17:21:03Z

<p>Peter Boot: /* Issues for next Telco - Oct 2008 */</p> <hr /> <div>== Council Telco - 21 August 2008 ==<br /> Minutes of the last meeting: http://www.tei-c.org/Activities/Council/Meetings/tcm39.xml<br /> == Issues for next Telco - Oct 2008 ==<br /> * placement of Schematron rules in ODD<br /> http://lists.village.virginia.edu/pipermail/tei-council/2008/010033.html<br /> * update on '&quot;getting started&quot;', see https://USER@tei.svn.sourceforge.net/svnroot/tei/trunk/Documents/GettingStarted (replacing 'USER' with your SourceForge username) and [[Getting Started]]<br /> <br /> <br /> Note to be produced by SR<br /> <br /> == Issues for next F2F ==<br /> <br /> * Discussion on ODD and its evolution--[[User:Romary|Romary]] 02:34, 9 September 2008 (EDT)<br /> <br /> cf. @usage in elementSpec<br /> <br /> == Highlights to be brought to the TEI MM 2008 ==<br /> <br /> <br /> == Topics (could be moved up to one F2F or Telco meeting ==<br /> <br /> * Stable reference to TEI objects<br /> <br /> [LR] In many cases, one has to map schemas and describe the mappings by reference to actual objects in the respective encoding schemes. In this context do (should) we have a mechanism to refer uniquely to TEI objects, beyond the reference to the TEI namespace (&lt;author&gt; in http://www.tei-c.org/ns/1.0), sort of TEI unique identifiers?<br /> <br /> [JC] I'd think the proper way to cite an element, class, or datatype generally is to point to its reference page. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-tree.html<br /> <br /> However, we might want to re-examine that... while the hierarchy should remain the same, deprecated elements (etc.) disappear. I have no way easy way to point to something at a particular date in time...unless maybe I point to it at a particular revision in the SVN source tree?<br /> <br /> Pointing to a location in the SVN source tree isn't necessarily very pretty but does work and is accurate:<br /> <br /> See for example an earlier version of &lt;event&gt;: http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?revision=231&amp;view=markup<br /> <br /> As a cognate example, I can point to any revision of a page in the TEI wiki at any point in its history. We should be able to do this, somehow, in the official way we are meant to cite TEI sources as changing objects in time.<br /> <br /> However, maybe an easier solution is to cite:<br /> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-event.html<br /> but on the generated reference pages like this contain a link to the appropriate place in the SVN repository? i.e.<br /> http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/event.xml?view=log <br /> which lists all the revisions.<br /> <br /> [AC] The only place on the website where I am ware there are some recommendations with URLs is the citation page:<br /> http://www.tei-c.org/Guidelines/access.xml<br /> <br /> This could certainly be enriched with notes on how to point to an element on the line James suggests, but in that case would the version number be enough to point to particular revisions?<br /> <br /> [DS] As an alternative to using a TEI-specific convention for citing URLs, we<br /> might want to consider adopting one or another of the standard systems<br /> for permanent identifiers, for example DOI (Digital Object Identifier).<br /> <br /> In the case of DOI, there would be some fairly minimal costs involved to<br /> register the DOIs with one of the national registries, but some more<br /> extensive costs in human time to set up a good system for mapping from<br /> our existing nomenclature to a set of DOI identifiers. (Publishers<br /> typically use DOIs to identify individual books or journal articles, but<br /> they can be more granular: every reference page in the Guidelines could<br /> have its own DOI, for example.)<br /> <br /> The advantage of doing this would be that anyone accustomed to using<br /> DOIs for citations could simply cite a DOI. So instead of the reference<br /> for &lt;name&gt; in the Guidelines<br /> <br /> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-name.html<br /> <br /> we would use something like<br /> <br /> doi:10.1111/tei-p5-doc:en:ref-name.html<br /> <br /> which would be resolved to the actual Web address by a DOI resolver.<br /> (Many journal DOIs are mostly numeric but the syntax allows more<br /> human-readable names).<br /> <br /> If we seriously want to consider an option like this, we should put out<br /> a call to the librarians/metadata gurus in our community for assistance<br /> with implementation.<br /> <br /> [PB] The latter is certainly much more elegant and resistant to change. I'd remove the '.html' at the end. HTML might be yesteryear's fashion a few years from now :-)<br /> <br /> == Misc. ==<br /> For general information concerning the council see [[TEI-Council-FAQ]]<br /> <br /> <br /> [[Category:Council]]<br /> Page and category reserved for use by TEI Council...</div>

Peter Boot https://wiki.tei-c.org/index.php?title=About_Getting_Started&diff=4591 2008-09-12T17:03:18Z

<p>Peter Boot: /* Technical setup */</p> <hr /> <div>Here we document, for the time being, arguments and decisions about the contents, the audience, the writing style etc. of the 'Getting started' document. Here is the outline of the Getting Started Document: [[Getting Started]]<br /> <br /> ==Purpose==<br /> * Someone that has read this document and that has gone through the steps the document describes (installing and using an editor, etc.) should be able to create, modify and validate a simple TEI document. He/she should be able to create an HTML representation of that document. He/she should also be able to assess the hurdles he/she faces in using TEI in his/her project and to decide on a proper course of action (e.g.: undertake project on his/her own, seek help in local institution or in wider TEI community, seek formal training). <br /> ==Audience== <br /> * The document targets an academic (postgraduate, PhD, researcher, professor) that wants to start understanding and using the TEI: e.g. a graduate student who wants to make an edition of a book he/she is writing a thesis on. The document assumes someone working on his/her own, willing to learn something new, ready to work hard and to try various solutions. We assume someone that is reasonably comfortable using computers, but has no experience in programming and no previous knowledge of XML or HTML. <br /> * Secondarily, we should also include in our target audience people who are not themselves scholars but who are, or will be, working as encoders with a project. These may be undergraduates, editorial assistants, etc. We can assume that they are equally motivated with the academic readers, but they may not be familiar with the technical vocabulary of textual studies, bibliography, etc.<br /> <br /> ==Software==<br /> * Because we want to help people getting started, there is no way we can avoid talking about specific software programs. We must be specific. Neither can we avoid talking about commercial software, as oXygen is the environment of choice for so many people using TEI. <br /> * We should avoid the editors that are favoured by programmers and other technically oriented persons, such as emacs or vi. We want to minimise the learning effort expended on tools; what people should learn here is the TEI.<br /> * What we also want to avoid are expensive editors. We're writing this for people that are getting started. They are probably unwilling to invest a large amount of money.<br /> * If possible, we should avoid command-line tools. In fact, we want to recommend an editor that comes with validation and facilities for running a transformation. <br /> * We should try to discuss editors that work on the three major platforms. <br /> * The upshot of this is, for me: we discuss oXygen (inexpensive, works everywhere, very powerful, but not open source) and the XML Copy editor (Open source, works on Windows and Linux, reasonably powerful). Arianna suggests including jEdit.<br /> * All of these either come with an xslt processor (oXygen and XML Copy editor) or have a plugin for the purpose (jEdit).<br /> * The 'official' document will be based on oXygen. Other versions will be placed on the TEI wiki. <br /> <br /> ==Schema's and ODD==<br /> * From a logical point of view, for any project that uses the TEI, ODD is the starting point. ODD helps you make a schema and the schema helps you create and validate xml documents. From an educational point of view, however, it makes more sense to start with an XML transcription of a document, and introduce the schema after that. A schema, let alone ODD, makes no sense to someone who is not familiar with xml documents. Therefore, the idea of making a schema that fits your documents, and the way of making such a schema, is introduced only after the reader is familiar with modifying and validating XML documents. <br /> <br /> ==Contents==<br /> * As to TEI elements, this document stresses elementary things such as div, p, lg, l, hi, etc. As a TEI document must have a header, it will mention the header and provide some instruction for filling it, but it will focus on quickly attaining results, rather that on the administrative side of things.<br /> * As to schema's: throughout the getting started document, we use RELAX NG. We mention DTD's and W3C Schema's as an option, without going into their syntax. We explain RELAX using the XML syntax, and mention the existence of the compact syntax.<br /> * As to XSLT: the document will explain some of the concepts of XSLT (templates, XPATH, ...), and it will encourage readers to make some small changes to a toy stylesheet. It will discuss the stylesheets provided by the TEI and guide readers in making a simple customisation. It will not try to provide further instruction in XSLT.<br /> <br /> ==Style==<br /> * We should try to be as clear and simple as possible. In a way, council members are not the best persons to write this document, as they may be too familiar with the technicalities to avoid terminology not immediately clear to beginners. We should be prepared to have this document reviewed by people less experienced in TEI and XML than we are. <br /> * Evidently, divisions of this document authored by non-native speakers of English should be reviewed by native speakers. <br /> <br /> ==Media use==<br /> * The document should include lots of screen shots. It may also contains links to video's of screen capture.<br /> <br /> ==Technical setup==<br /> * The document is stored in Subversion in SourceForge. The relevant folder is [https://tei.svn.sourceforge.net/svnroot/tei/trunk/Documents/GettingStarted https://tei.svn.sourceforge.net/svnroot/tei/trunk/Documents/GettingStarted]. There is a main document (gettingstarted.xml) that includes the separate sections using XInclude. This makes it easier for multiple people to work on the document simultaneously. Editors without SourceForge access can mail updated sections to Peter, who will then add them in SoureForge.<br /> * all sections carry xml:id-attributes. As we should assume new sections will be added or sections will be moved around, top-level sections are identified using two-letter abbreviations. <br /> * names of elements, attributes, etc are tagged using the appropriate elements from the documentation tagset (&amp;lt;att&gt;, &amp;lt;gi&gt;, &amp;lt;ident&gt;)<br /> * images are stored in a subfolder 'images' of the main Subversion folder<br /> * abbreviations and other technical terms refer to entries in the Glossary using &amp;lt;ref&gt; elements<br /> * examples will be numbered by the stylesheet. We provide them with id attributes with values 'xaabbb', where 'x' is a literal, 'aa' is the section id and 'bbb' is an acronym for the example, unique in that section of the document. Refer to the examples using &amp;lt;ptr&gt;</div>

Peter Boot https://wiki.tei-c.org/index.php?title=About_Getting_Started&diff=4590 2008-09-12T17:03:03Z

<p>Peter Boot: /* Technical setup */</p> <hr /> <div>Here we document, for the time being, arguments and decisions about the contents, the audience, the writing style etc. of the 'Getting started' document. Here is the outline of the Getting Started Document: [[Getting Started]]<br /> <br /> ==Purpose==<br /> * Someone that has read this document and that has gone through the steps the document describes (installing and using an editor, etc.) should be able to create, modify and validate a simple TEI document. He/she should be able to create an HTML representation of that document. He/she should also be able to assess the hurdles he/she faces in using TEI in his/her project and to decide on a proper course of action (e.g.: undertake project on his/her own, seek help in local institution or in wider TEI community, seek formal training). <br /> ==Audience== <br /> * The document targets an academic (postgraduate, PhD, researcher, professor) that wants to start understanding and using the TEI: e.g. a graduate student who wants to make an edition of a book he/she is writing a thesis on. The document assumes someone working on his/her own, willing to learn something new, ready to work hard and to try various solutions. We assume someone that is reasonably comfortable using computers, but has no experience in programming and no previous knowledge of XML or HTML. <br /> * Secondarily, we should also include in our target audience people who are not themselves scholars but who are, or will be, working as encoders with a project. These may be undergraduates, editorial assistants, etc. We can assume that they are equally motivated with the academic readers, but they may not be familiar with the technical vocabulary of textual studies, bibliography, etc.<br /> <br /> ==Software==<br /> * Because we want to help people getting started, there is no way we can avoid talking about specific software programs. We must be specific. Neither can we avoid talking about commercial software, as oXygen is the environment of choice for so many people using TEI. <br /> * We should avoid the editors that are favoured by programmers and other technically oriented persons, such as emacs or vi. We want to minimise the learning effort expended on tools; what people should learn here is the TEI.<br /> * What we also want to avoid are expensive editors. We're writing this for people that are getting started. They are probably unwilling to invest a large amount of money.<br /> * If possible, we should avoid command-line tools. In fact, we want to recommend an editor that comes with validation and facilities for running a transformation. <br /> * We should try to discuss editors that work on the three major platforms. <br /> * The upshot of this is, for me: we discuss oXygen (inexpensive, works everywhere, very powerful, but not open source) and the XML Copy editor (Open source, works on Windows and Linux, reasonably powerful). Arianna suggests including jEdit.<br /> * All of these either come with an xslt processor (oXygen and XML Copy editor) or have a plugin for the purpose (jEdit).<br /> * The 'official' document will be based on oXygen. Other versions will be placed on the TEI wiki. <br /> <br /> ==Schema's and ODD==<br /> * From a logical point of view, for any project that uses the TEI, ODD is the starting point. ODD helps you make a schema and the schema helps you create and validate xml documents. From an educational point of view, however, it makes more sense to start with an XML transcription of a document, and introduce the schema after that. A schema, let alone ODD, makes no sense to someone who is not familiar with xml documents. Therefore, the idea of making a schema that fits your documents, and the way of making such a schema, is introduced only after the reader is familiar with modifying and validating XML documents. <br /> <br /> ==Contents==<br /> * As to TEI elements, this document stresses elementary things such as div, p, lg, l, hi, etc. As a TEI document must have a header, it will mention the header and provide some instruction for filling it, but it will focus on quickly attaining results, rather that on the administrative side of things.<br /> * As to schema's: throughout the getting started document, we use RELAX NG. We mention DTD's and W3C Schema's as an option, without going into their syntax. We explain RELAX using the XML syntax, and mention the existence of the compact syntax.<br /> * As to XSLT: the document will explain some of the concepts of XSLT (templates, XPATH, ...), and it will encourage readers to make some small changes to a toy stylesheet. It will discuss the stylesheets provided by the TEI and guide readers in making a simple customisation. It will not try to provide further instruction in XSLT.<br /> <br /> ==Style==<br /> * We should try to be as clear and simple as possible. In a way, council members are not the best persons to write this document, as they may be too familiar with the technicalities to avoid terminology not immediately clear to beginners. We should be prepared to have this document reviewed by people less experienced in TEI and XML than we are. <br /> * Evidently, divisions of this document authored by non-native speakers of English should be reviewed by native speakers. <br /> <br /> ==Media use==<br /> * The document should include lots of screen shots. It may also contains links to video's of screen capture.<br /> <br /> ==Technical setup==<br /> * The document is stored in Subversion in SourceForge. The relevant folder is [https://tei.svn.sourceforge.net/svnroot/tei/trunk/Documents/GettingStarted https://tei.svn.sourceforge.net/svnroot/tei/trunk/Documents/GettingStarted] There is a main document (gettingstarted.xml) that includes the separate sections using XInclude. This makes it easier for multiple people to work on the document simultaneously. Editors without SourceForge access can mail updated sections to Peter, who will then add them in SoureForge.<br /> * all sections carry xml:id-attributes. As we should assume new sections will be added or sections will be moved around, top-level sections are identified using two-letter abbreviations. <br /> * names of elements, attributes, etc are tagged using the appropriate elements from the documentation tagset (&amp;lt;att&gt;, &amp;lt;gi&gt;, &amp;lt;ident&gt;)<br /> * images are stored in a subfolder 'images' of the main Subversion folder<br /> * abbreviations and other technical terms refer to entries in the Glossary using &amp;lt;ref&gt; elements<br /> * examples will be numbered by the stylesheet. We provide them with id attributes with values 'xaabbb', where 'x' is a literal, 'aa' is the section id and 'bbb' is an acronym for the example, unique in that section of the document. Refer to the examples using &amp;lt;ptr&gt;</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4589 2008-09-12T16:59:04Z

<p>Peter Boot: </p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]]. Here is the provisional result: [http://peterboot.nl/tei/gs.html http://peterboot.nl/tei/gs.html]<br /> <br /> ==Introduction (Peter) ==<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ===What this document does, and what it doesn't===<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ==Should you use TEI?==<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ==Technical background==<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ==Overall structure of a TEI text==<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ==The rationale of declarative markup==<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ==Choosing and installing an editor==<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ==Load, modify, validate a complete ready-made document==<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ==Running stylesheets ==<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ==Getting this to work on sample of own text==<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ==Schema's==<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ==Where to go from here==<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ==Glossary==<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ==Literature==<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4588 2008-09-12T16:57:26Z

<p>Peter Boot: </p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]]. Here is the provisional result: [http://peterboot.nl/tei/gs.html]<br /> <br /> ==Introduction (Peter) ==<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ===What this document does, and what it doesn't===<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ==Should you use TEI?==<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ==Technical background==<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ==Overall structure of a TEI text==<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ==The rationale of declarative markup==<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ==Choosing and installing an editor==<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ==Load, modify, validate a complete ready-made document==<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ==Running stylesheets ==<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ==Getting this to work on sample of own text==<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ==Schema's==<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ==Where to go from here==<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ==Glossary==<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ==Literature==<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4587 2008-09-12T15:47:07Z

<p>Peter Boot: /* Introduction (Peter) */</p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]] <br /> <br /> ==Introduction (Peter) ==<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ===What this document does, and what it doesn't===<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ==Should you use TEI?==<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ==Technical background==<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ==Overall structure of a TEI text==<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ==The rationale of declarative markup==<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ==Choosing and installing an editor==<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ==Load, modify, validate a complete ready-made document==<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ==Running stylesheets ==<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ==Getting this to work on sample of own text==<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ==Schema's==<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ==Where to go from here==<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ==Glossary==<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ==Literature==<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=About_Getting_Started&diff=4586 2008-09-12T15:34:44Z

<p>Peter Boot: /* Technical setup */</p> <hr /> <div>Here we document, for the time being, arguments and decisions about the contents, the audience, the writing style etc. of the 'Getting started' document. Here is the outline of the Getting Started Document: [[Getting Started]]<br /> <br /> ==Purpose==<br /> * Someone that has read this document and that has gone through the steps the document describes (installing and using an editor, etc.) should be able to create, modify and validate a simple TEI document. He/she should be able to create an HTML representation of that document. He/she should also be able to assess the hurdles he/she faces in using TEI in his/her project and to decide on a proper course of action (e.g.: undertake project on his/her own, seek help in local institution or in wider TEI community, seek formal training). <br /> ==Audience== <br /> * The document targets an academic (postgraduate, PhD, researcher, professor) that wants to start understanding and using the TEI: e.g. a graduate student who wants to make an edition of a book he/she is writing a thesis on. The document assumes someone working on his/her own, willing to learn something new, ready to work hard and to try various solutions. We assume someone that is reasonably comfortable using computers, but has no experience in programming and no previous knowledge of XML or HTML. <br /> * Secondarily, we should also include in our target audience people who are not themselves scholars but who are, or will be, working as encoders with a project. These may be undergraduates, editorial assistants, etc. We can assume that they are equally motivated with the academic readers, but they may not be familiar with the technical vocabulary of textual studies, bibliography, etc.<br /> <br /> ==Software==<br /> * Because we want to help people getting started, there is no way we can avoid talking about specific software programs. We must be specific. Neither can we avoid talking about commercial software, as oXygen is the environment of choice for so many people using TEI. <br /> * We should avoid the editors that are favoured by programmers and other technically oriented persons, such as emacs or vi. We want to minimise the learning effort expended on tools; what people should learn here is the TEI.<br /> * What we also want to avoid are expensive editors. We're writing this for people that are getting started. They are probably unwilling to invest a large amount of money.<br /> * If possible, we should avoid command-line tools. In fact, we want to recommend an editor that comes with validation and facilities for running a transformation. <br /> * We should try to discuss editors that work on the three major platforms. <br /> * The upshot of this is, for me: we discuss oXygen (inexpensive, works everywhere, very powerful, but not open source) and the XML Copy editor (Open source, works on Windows and Linux, reasonably powerful). Arianna suggests including jEdit.<br /> * All of these either come with an xslt processor (oXygen and XML Copy editor) or have a plugin for the purpose (jEdit).<br /> * The 'official' document will be based on oXygen. Other versions will be placed on the TEI wiki. <br /> <br /> ==Schema's and ODD==<br /> * From a logical point of view, for any project that uses the TEI, ODD is the starting point. ODD helps you make a schema and the schema helps you create and validate xml documents. From an educational point of view, however, it makes more sense to start with an XML transcription of a document, and introduce the schema after that. A schema, let alone ODD, makes no sense to someone who is not familiar with xml documents. Therefore, the idea of making a schema that fits your documents, and the way of making such a schema, is introduced only after the reader is familiar with modifying and validating XML documents. <br /> <br /> ==Contents==<br /> * As to TEI elements, this document stresses elementary things such as div, p, lg, l, hi, etc. As a TEI document must have a header, it will mention the header and provide some instruction for filling it, but it will focus on quickly attaining results, rather that on the administrative side of things.<br /> * As to schema's: throughout the getting started document, we use RELAX NG. We mention DTD's and W3C Schema's as an option, without going into their syntax. We explain RELAX using the XML syntax, and mention the existence of the compact syntax.<br /> * As to XSLT: the document will explain some of the concepts of XSLT (templates, XPATH, ...), and it will encourage readers to make some small changes to a toy stylesheet. It will discuss the stylesheets provided by the TEI and guide readers in making a simple customisation. It will not try to provide further instruction in XSLT.<br /> <br /> ==Style==<br /> * We should try to be as clear and simple as possible. In a way, council members are not the best persons to write this document, as they may be too familiar with the technicalities to avoid terminology not immediately clear to beginners. We should be prepared to have this document reviewed by people less experienced in TEI and XML than we are. <br /> * Evidently, divisions of this document authored by non-native speakers of English should be reviewed by native speakers. <br /> <br /> ==Media use==<br /> * The document should include lots of screen shots. It may also contains links to video's of screen capture.<br /> <br /> ==Technical setup==<br /> * The document is stored in Subversion in SourceForge. There is a main document (gettingstarted.xml) that includes the separate sections using XInclude. This makes it easier for multiple people to work on the document simultaneously. Editors without SourceForge access can mail updated sections to Peter, who will then add them in SoureForge.<br /> * all sections carry xml:id-attributes. As we should assume new sections will be added or sections will be moved around, top-level sections are identified using two-letter abbreviations. <br /> * names of elements, attributes, etc are tagged using the appropriate elements from the documentation tagset (&amp;lt;att&gt;, &amp;lt;gi&gt;, &amp;lt;ident&gt;)<br /> * images are stored in a subfolder 'images' of the main Subversion folder<br /> * abbreviations and other technical terms refer to entries in the Glossary using &amp;lt;ref&gt; elements<br /> * examples will be numbered by the stylesheet. We provide them with id attributes with values 'xaabbb', where 'x' is a literal, 'aa' is the section id and 'bbb' is an acronym for the example, unique in that section of the document. Refer to the examples using &amp;lt;ptr&gt;</div>

Peter Boot https://wiki.tei-c.org/index.php?title=About_Getting_Started&diff=4585 2008-09-12T15:34:02Z

<p>Peter Boot: /* Technical setup */</p> <hr /> <div>Here we document, for the time being, arguments and decisions about the contents, the audience, the writing style etc. of the 'Getting started' document. Here is the outline of the Getting Started Document: [[Getting Started]]<br /> <br /> ==Purpose==<br /> * Someone that has read this document and that has gone through the steps the document describes (installing and using an editor, etc.) should be able to create, modify and validate a simple TEI document. He/she should be able to create an HTML representation of that document. He/she should also be able to assess the hurdles he/she faces in using TEI in his/her project and to decide on a proper course of action (e.g.: undertake project on his/her own, seek help in local institution or in wider TEI community, seek formal training). <br /> ==Audience== <br /> * The document targets an academic (postgraduate, PhD, researcher, professor) that wants to start understanding and using the TEI: e.g. a graduate student who wants to make an edition of a book he/she is writing a thesis on. The document assumes someone working on his/her own, willing to learn something new, ready to work hard and to try various solutions. We assume someone that is reasonably comfortable using computers, but has no experience in programming and no previous knowledge of XML or HTML. <br /> * Secondarily, we should also include in our target audience people who are not themselves scholars but who are, or will be, working as encoders with a project. These may be undergraduates, editorial assistants, etc. We can assume that they are equally motivated with the academic readers, but they may not be familiar with the technical vocabulary of textual studies, bibliography, etc.<br /> <br /> ==Software==<br /> * Because we want to help people getting started, there is no way we can avoid talking about specific software programs. We must be specific. Neither can we avoid talking about commercial software, as oXygen is the environment of choice for so many people using TEI. <br /> * We should avoid the editors that are favoured by programmers and other technically oriented persons, such as emacs or vi. We want to minimise the learning effort expended on tools; what people should learn here is the TEI.<br /> * What we also want to avoid are expensive editors. We're writing this for people that are getting started. They are probably unwilling to invest a large amount of money.<br /> * If possible, we should avoid command-line tools. In fact, we want to recommend an editor that comes with validation and facilities for running a transformation. <br /> * We should try to discuss editors that work on the three major platforms. <br /> * The upshot of this is, for me: we discuss oXygen (inexpensive, works everywhere, very powerful, but not open source) and the XML Copy editor (Open source, works on Windows and Linux, reasonably powerful). Arianna suggests including jEdit.<br /> * All of these either come with an xslt processor (oXygen and XML Copy editor) or have a plugin for the purpose (jEdit).<br /> * The 'official' document will be based on oXygen. Other versions will be placed on the TEI wiki. <br /> <br /> ==Schema's and ODD==<br /> * From a logical point of view, for any project that uses the TEI, ODD is the starting point. ODD helps you make a schema and the schema helps you create and validate xml documents. From an educational point of view, however, it makes more sense to start with an XML transcription of a document, and introduce the schema after that. A schema, let alone ODD, makes no sense to someone who is not familiar with xml documents. Therefore, the idea of making a schema that fits your documents, and the way of making such a schema, is introduced only after the reader is familiar with modifying and validating XML documents. <br /> <br /> ==Contents==<br /> * As to TEI elements, this document stresses elementary things such as div, p, lg, l, hi, etc. As a TEI document must have a header, it will mention the header and provide some instruction for filling it, but it will focus on quickly attaining results, rather that on the administrative side of things.<br /> * As to schema's: throughout the getting started document, we use RELAX NG. We mention DTD's and W3C Schema's as an option, without going into their syntax. We explain RELAX using the XML syntax, and mention the existence of the compact syntax.<br /> * As to XSLT: the document will explain some of the concepts of XSLT (templates, XPATH, ...), and it will encourage readers to make some small changes to a toy stylesheet. It will discuss the stylesheets provided by the TEI and guide readers in making a simple customisation. It will not try to provide further instruction in XSLT.<br /> <br /> ==Style==<br /> * We should try to be as clear and simple as possible. In a way, council members are not the best persons to write this document, as they may be too familiar with the technicalities to avoid terminology not immediately clear to beginners. We should be prepared to have this document reviewed by people less experienced in TEI and XML than we are. <br /> * Evidently, divisions of this document authored by non-native speakers of English should be reviewed by native speakers. <br /> <br /> ==Media use==<br /> * The document should include lots of screen shots. It may also contains links to video's of screen capture.<br /> <br /> ==Technical setup==<br /> * The document is stored in Subversion in SourceForge. There is a main document (gettingstarted.xml) that includes the separate sections using XInclude. This makes it easier for multiple people to work on the document simultaneously. Editors without SourceForge access can mail updated sections to Peter, who will then add them in SoureForge.<br /> * all sections carry xml:id-attributes. As we should assume new sections will be added or sections will be moved around, top-level sections are identified using two-letter abbreviations. <br /> * names of elements, attributes, etc are tagged using the appropriate elements from the documentation tagset (&amp;lt;att&gt;, &amp;lt;gi&gt;, &amp;lt;ident&gt;)<br /> * images are stored in a subfolder 'images' of the main Subversion folder<br /> * abbreviations and other technical terms refer to entries in the Glossary using &amp;lt;ref&gt; elements<br /> * examples will be numbered by the stylesheet. We provide them with id attributes with values 'xaabbb', where 'x' is a literal, 'aa' is the section id and 'bbb' is an acronym for the example, unique in that section of the document</div>

Peter Boot https://wiki.tei-c.org/index.php?title=About_Getting_Started&diff=4584 2008-09-12T13:42:14Z

<p>Peter Boot: refs to glossary</p> <hr /> <div>Here we document, for the time being, arguments and decisions about the contents, the audience, the writing style etc. of the 'Getting started' document. Here is the outline of the Getting Started Document: [[Getting Started]]<br /> <br /> ==Purpose==<br /> * Someone that has read this document and that has gone through the steps the document describes (installing and using an editor, etc.) should be able to create, modify and validate a simple TEI document. He/she should be able to create an HTML representation of that document. He/she should also be able to assess the hurdles he/she faces in using TEI in his/her project and to decide on a proper course of action (e.g.: undertake project on his/her own, seek help in local institution or in wider TEI community, seek formal training). <br /> ==Audience== <br /> * The document targets an academic (postgraduate, PhD, researcher, professor) that wants to start understanding and using the TEI: e.g. a graduate student who wants to make an edition of a book he/she is writing a thesis on. The document assumes someone working on his/her own, willing to learn something new, ready to work hard and to try various solutions. We assume someone that is reasonably comfortable using computers, but has no experience in programming and no previous knowledge of XML or HTML. <br /> * Secondarily, we should also include in our target audience people who are not themselves scholars but who are, or will be, working as encoders with a project. These may be undergraduates, editorial assistants, etc. We can assume that they are equally motivated with the academic readers, but they may not be familiar with the technical vocabulary of textual studies, bibliography, etc.<br /> <br /> ==Software==<br /> * Because we want to help people getting started, there is no way we can avoid talking about specific software programs. We must be specific. Neither can we avoid talking about commercial software, as oXygen is the environment of choice for so many people using TEI. <br /> * We should avoid the editors that are favoured by programmers and other technically oriented persons, such as emacs or vi. We want to minimise the learning effort expended on tools; what people should learn here is the TEI.<br /> * What we also want to avoid are expensive editors. We're writing this for people that are getting started. They are probably unwilling to invest a large amount of money.<br /> * If possible, we should avoid command-line tools. In fact, we want to recommend an editor that comes with validation and facilities for running a transformation. <br /> * We should try to discuss editors that work on the three major platforms. <br /> * The upshot of this is, for me: we discuss oXygen (inexpensive, works everywhere, very powerful, but not open source) and the XML Copy editor (Open source, works on Windows and Linux, reasonably powerful). Arianna suggests including jEdit.<br /> * All of these either come with an xslt processor (oXygen and XML Copy editor) or have a plugin for the purpose (jEdit).<br /> * The 'official' document will be based on oXygen. Other versions will be placed on the TEI wiki. <br /> <br /> ==Schema's and ODD==<br /> * From a logical point of view, for any project that uses the TEI, ODD is the starting point. ODD helps you make a schema and the schema helps you create and validate xml documents. From an educational point of view, however, it makes more sense to start with an XML transcription of a document, and introduce the schema after that. A schema, let alone ODD, makes no sense to someone who is not familiar with xml documents. Therefore, the idea of making a schema that fits your documents, and the way of making such a schema, is introduced only after the reader is familiar with modifying and validating XML documents. <br /> <br /> ==Contents==<br /> * As to TEI elements, this document stresses elementary things such as div, p, lg, l, hi, etc. As a TEI document must have a header, it will mention the header and provide some instruction for filling it, but it will focus on quickly attaining results, rather that on the administrative side of things.<br /> * As to schema's: throughout the getting started document, we use RELAX NG. We mention DTD's and W3C Schema's as an option, without going into their syntax. We explain RELAX using the XML syntax, and mention the existence of the compact syntax.<br /> * As to XSLT: the document will explain some of the concepts of XSLT (templates, XPATH, ...), and it will encourage readers to make some small changes to a toy stylesheet. It will discuss the stylesheets provided by the TEI and guide readers in making a simple customisation. It will not try to provide further instruction in XSLT.<br /> <br /> ==Style==<br /> * We should try to be as clear and simple as possible. In a way, council members are not the best persons to write this document, as they may be too familiar with the technicalities to avoid terminology not immediately clear to beginners. We should be prepared to have this document reviewed by people less experienced in TEI and XML than we are. <br /> * Evidently, divisions of this document authored by non-native speakers of English should be reviewed by native speakers. <br /> <br /> ==Media use==<br /> * The document should include lots of screen shots. It may also contains links to video's of screen capture.<br /> <br /> ==Technical setup==<br /> * The document is stored in Subversion in SourceForge. There is a main document (gettingstarted.xml) that includes the separate sections using XInclude. This makes it easier for multiple people to work on the document simultaneously. Editors without SourceForge access can mail updated sections to Peter, who will then add them in SoureForge.<br /> * all sections carry xml:id-attributes. As we should assume new sections will be added or sections will be moved around, top-level sections are identified using two-letter abbreviations. <br /> * names of elements, attributes, etc are tagged using the appropriate elements from the documentation tagset (&amp;lt;att&gt;, &amp;lt;gi&gt;, &amp;lt;ident&gt;)<br /> * images are stored in a subfolder 'images' of the main Subversion folder<br /> * abbreviations refer to entries in the Glossary using &amp;lt;ref&gt; elements</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4583 2008-09-12T11:32:16Z

<p>Peter Boot: </p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]] <br /> <br /> ==Introduction (Peter) ==<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ===What this document does, and what it doesn't===<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ===Conventions used in this document===<br /> * How we label examples, program names, elements and attributes. 1p<br /> * How this document serves users on different platforms. 1p<br /> <br /> ==Should you use TEI?==<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ==Technical background==<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ==Overall structure of a TEI text==<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ==The rationale of declarative markup==<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ==Choosing and installing an editor==<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ==Load, modify, validate a complete ready-made document==<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ==Running stylesheets ==<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ==Getting this to work on sample of own text==<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ==Schema's==<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ==Where to go from here==<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ==Glossary==<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ==Literature==<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4582 2008-09-12T11:30:04Z

<p>Peter Boot: </p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]] <br /> <br /> ===Introduction (Peter) ===<br /> <br /> ====TEI: a very high-level overview====<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ====What this document does, and what it doesn't====<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ====Conventions used in this document====<br /> * How we label examples, program names, elements and attributes. 1p<br /> * How this document serves users on different platforms. 1p<br /> <br /> ===Should you use TEI?===<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ===Technical background===<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ===Overall structure of a TEI text===<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ===The rationale of declarative markup===<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ===Choosing and installing an editor===<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ===Load, modify, validate a complete ready-made document===<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ===Running stylesheets ===<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ===Getting this to work on sample of own text===<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ===Schema's===<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ===Where to go from here===<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ===Glossary===<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ===Literature===<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4581 2008-09-12T11:29:07Z

<p>Peter Boot: </p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]] <br /> <br /> ===Introduction (Peter) ===<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ====What this document does, and what it doesn't====<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ====Conventions used in this document====<br /> * How we label examples, program names, elements and attributes. 1p<br /> * How this document serves users on different platforms. 1p<br /> <br /> ===Should you use TEI?===<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ===Technical background===<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ===Overall structure of a TEI text===<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ===The rationale of declarative markup===<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ===Choosing and installing an editor===<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ===Load, modify, validate a complete ready-made document===<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ===Running stylesheets ===<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ===Getting this to work on sample of own text===<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ===Schema's===<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ===Where to go from here===<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ===Glossary===<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ===Literature===<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4580 2008-09-12T11:28:52Z

<p>Peter Boot: </p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. There is a separate page about the desired contents, style, setup, etc. of the document: [[About Getting Started]] <br /> <br /> ===Introduction (Peter) ===<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ====What this document does, and what it doesn't====<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ====Conventions used in this document====<br /> * How we label examples, program names, elements and attributes. 1p<br /> * How this document serves users on different platforms. 1p<br /> <br /> ===Should you use TEI?===<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ===Technical background===<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ===Overall structure of a TEI text===<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ===The rationale of declarative markup===<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ===Choosing and installing an editor===<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ===Load, modify, validate a complete ready-made document===<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ===Running stylesheets ===<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ===Getting this to work on sample of own text===<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ===Schema's===<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ===Where to go from here===<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ===Glossary===<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ===Literature===<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=About_Getting_Started&diff=4579 2008-09-12T11:27:20Z

<p>Peter Boot: </p> <hr /> <div>Here we document, for the time being, arguments and decisions about the contents, the audience, the writing style etc. of the 'Getting started' document. Here is the outline of the Getting Started Document: [[Getting Started]]<br /> <br /> ==Purpose==<br /> * Someone that has read this document and that has gone through the steps the document describes (installing and using an editor, etc.) should be able to create, modify and validate a simple TEI document. He/she should be able to create an HTML representation of that document. He/she should also be able to assess the hurdles he/she faces in using TEI in his/her project and to decide on a proper course of action (e.g.: undertake project on his/her own, seek help in local institution or in wider TEI community, seek formal training). <br /> ==Audience== <br /> * The document targets an academic (postgraduate, PhD, researcher, professor) that wants to start understanding and using the TEI: e.g. a graduate student who wants to make an edition of a book he/she is writing a thesis on. The document assumes someone working on his/her own, willing to learn something new, ready to work hard and to try various solutions. We assume someone that is reasonably comfortable using computers, but has no experience in programming and no previous knowledge of XML or HTML. <br /> * Secondarily, we should also include in our target audience people who are not themselves scholars but who are, or will be, working as encoders with a project. These may be undergraduates, editorial assistants, etc. We can assume that they are equally motivated with the academic readers, but they may not be familiar with the technical vocabulary of textual studies, bibliography, etc.<br /> <br /> ==Software==<br /> * Because we want to help people getting started, there is no way we can avoid talking about specific software programs. We must be specific. Neither can we avoid talking about commercial software, as oXygen is the environment of choice for so many people using TEI. <br /> * We should avoid the editors that are favoured by programmers and other technically oriented persons, such as emacs or vi. We want to minimise the learning effort expended on tools; what people should learn here is the TEI.<br /> * What we also want to avoid are expensive editors. We're writing this for people that are getting started. They are probably unwilling to invest a large amount of money.<br /> * If possible, we should avoid command-line tools. In fact, we want to recommend an editor that comes with validation and facilities for running a transformation. <br /> * We should try to discuss editors that work on the three major platforms. <br /> * The upshot of this is, for me: we discuss oXygen (inexpensive, works everywhere, very powerful, but not open source) and the XML Copy editor (Open source, works on Windows and Linux, reasonably powerful). Arianna suggests including jEdit.<br /> * All of these either come with an xslt processor (oXygen and XML Copy editor) or have a plugin for the purpose (jEdit).<br /> * The 'official' document will be based on oXygen. Other versions will be placed on the TEI wiki. <br /> <br /> ==Schema's and ODD==<br /> * From a logical point of view, for any project that uses the TEI, ODD is the starting point. ODD helps you make a schema and the schema helps you create and validate xml documents. From an educational point of view, however, it makes more sense to start with an XML transcription of a document, and introduce the schema after that. A schema, let alone ODD, makes no sense to someone who is not familiar with xml documents. Therefore, the idea of making a schema that fits your documents, and the way of making such a schema, is introduced only after the reader is familiar with modifying and validating XML documents. <br /> <br /> ==Contents==<br /> * As to TEI elements, this document stresses elementary things such as div, p, lg, l, hi, etc. As a TEI document must have a header, it will mention the header and provide some instruction for filling it, but it will focus on quickly attaining results, rather that on the administrative side of things.<br /> * As to schema's: throughout the getting started document, we use RELAX NG. We mention DTD's and W3C Schema's as an option, without going into their syntax. We explain RELAX using the XML syntax, and mention the existence of the compact syntax.<br /> * As to XSLT: the document will explain some of the concepts of XSLT (templates, XPATH, ...), and it will encourage readers to make some small changes to a toy stylesheet. It will discuss the stylesheets provided by the TEI and guide readers in making a simple customisation. It will not try to provide further instruction in XSLT.<br /> <br /> ==Style==<br /> * We should try to be as clear and simple as possible. In a way, council members are not the best persons to write this document, as they may be too familiar with the technicalities to avoid terminology not immediately clear to beginners. We should be prepared to have this document reviewed by people less experienced in TEI and XML than we are. <br /> * Evidently, divisions of this document authored by non-native speakers of English should be reviewed by native speakers. <br /> <br /> ==Media use==<br /> * The document should include lots of screen shots. It may also contains links to video's of screen capture.<br /> <br /> ==Technical setup==<br /> * The document is stored in Subversion in SourceForge. There is a main document (gettingstarted.xml) that includes the separate sections using XInclude. This makes it easier for multiple people to work on the document simultaneously. Editors without SourceForge access can mail updated sections to Peter, who will then add them in SoureForge.<br /> * all sections carry xml:id-attributes. As we should assume new sections will be added or sections will be moved around, top-level sections are identified using two-letter abbreviations. <br /> * names of elements, attributes, etc are tagged using the appropriate elements from the documentation tagset (att, gi, ident)<br /> * images are stored in a subfolder 'images' of the main Subversion folder</div>

Peter Boot https://wiki.tei-c.org/index.php?title=About_Getting_Started&diff=4578 2008-09-12T11:23:20Z

<p>Peter Boot: Added technical setup</p> <hr /> <div>Here we document, for the time being, arguments and decisions about the contents, the audience, the writing style etc. of the 'Getting started' document.<br /> <br /> ==Purpose==<br /> * Someone that has read this document and that has gone through the steps the document describes (installing and using an editor, etc.) should be able to create, modify and validate a simple TEI document. He/she should be able to create an HTML representation of that document. He/she should also be able to assess the hurdles he/she faces in using TEI in his/her project and to decide on a proper course of action (e.g.: undertake project on his/her own, seek help in local institution or in wider TEI community, seek formal training). <br /> ==Audience== <br /> * The document targets an academic (postgraduate, PhD, researcher, professor) that wants to start understanding and using the TEI: e.g. a graduate student who wants to make an edition of a book he/she is writing a thesis on. The document assumes someone working on his/her own, willing to learn something new, ready to work hard and to try various solutions. We assume someone that is reasonably comfortable using computers, but has no experience in programming and no previous knowledge of XML or HTML. <br /> * Secondarily, we should also include in our target audience people who are not themselves scholars but who are, or will be, working as encoders with a project. These may be undergraduates, editorial assistants, etc. We can assume that they are equally motivated with the academic readers, but they may not be familiar with the technical vocabulary of textual studies, bibliography, etc.<br /> <br /> ==Software==<br /> * Because we want to help people getting started, there is no way we can avoid talking about specific software programs. We must be specific. Neither can we avoid talking about commercial software, as oXygen is the environment of choice for so many people using TEI. <br /> * We should avoid the editors that are favoured by programmers and other technically oriented persons, such as emacs or vi. We want to minimise the learning effort expended on tools; what people should learn here is the TEI.<br /> * What we also want to avoid are expensive editors. We're writing this for people that are getting started. They are probably unwilling to invest a large amount of money.<br /> * If possible, we should avoid command-line tools. In fact, we want to recommend an editor that comes with validation and facilities for running a transformation. <br /> * We should try to discuss editors that work on the three major platforms. <br /> * The upshot of this is, for me: we discuss oXygen (inexpensive, works everywhere, very powerful, but not open source) and the XML Copy editor (Open source, works on Windows and Linux, reasonably powerful). Arianna suggests including jEdit.<br /> * All of these either come with an xslt processor (oXygen and XML Copy editor) or have a plugin for the purpose (jEdit).<br /> * The 'official' document will be based on oXygen. Other versions will be placed on the TEI wiki. <br /> <br /> ==Schema's and ODD==<br /> * From a logical point of view, for any project that uses the TEI, ODD is the starting point. ODD helps you make a schema and the schema helps you create and validate xml documents. From an educational point of view, however, it makes more sense to start with an XML transcription of a document, and introduce the schema after that. A schema, let alone ODD, makes no sense to someone who is not familiar with xml documents. Therefore, the idea of making a schema that fits your documents, and the way of making such a schema, is introduced only after the reader is familiar with modifying and validating XML documents. <br /> <br /> ==Contents==<br /> * As to TEI elements, this document stresses elementary things such as div, p, lg, l, hi, etc. As a TEI document must have a header, it will mention the header and provide some instruction for filling it, but it will focus on quickly attaining results, rather that on the administrative side of things.<br /> * As to schema's: throughout the getting started document, we use RELAX NG. We mention DTD's and W3C Schema's as an option, without going into their syntax. We explain RELAX using the XML syntax, and mention the existence of the compact syntax.<br /> * As to XSLT: the document will explain some of the concepts of XSLT (templates, XPATH, ...), and it will encourage readers to make some small changes to a toy stylesheet. It will discuss the stylesheets provided by the TEI and guide readers in making a simple customisation. It will not try to provide further instruction in XSLT.<br /> <br /> ==Style==<br /> * We should try to be as clear and simple as possible. In a way, council members are not the best persons to write this document, as they may be too familiar with the technicalities to avoid terminology not immediately clear to beginners. We should be prepared to have this document reviewed by people less experienced in TEI and XML than we are. <br /> * Evidently, divisions of this document authored by non-native speakers of English should be reviewed by native speakers. <br /> <br /> ==Media use==<br /> * The document should include lots of screen shots. It may also contains links to video's of screen capture.<br /> <br /> ==Technical setup==<br /> * The document is stored in Subversion in SourceForge. There is a main document (gettingstarted.xml) that includes the separate sections using XInclude. This makes it easier for multiple people to work on the document simultaneously. Editors without SourceForge access can mail updated sections to Peter, who will then add them in SoureForge.<br /> * all sections carry xml:id-attributes. As we should assume new sections will be added or sections will be moved around, top-level sections are identified using two-letter abbreviations. <br /> * names of elements, attributes, etc are tagged using the appropriate elements from the documentation tagset (att, gi, ident)<br /> * images are stored in a subfolder 'images' of the main Subversion folder</div>

Peter Boot https://wiki.tei-c.org/index.php?title=About_Getting_Started&diff=4577 2008-09-12T11:07:03Z

<p>Peter Boot: About the getting started document</p> <hr /> <div>Here we document, for the time being, arguments and decisions about the contents, the audience, the writing style etc. of the 'Getting started' document.<br /> <br /> ==Purpose==<br /> Someone that has read this document and that has gone through the steps the document describes (installing and using an editor, etc.) should be able to create, modify and validate a simple TEI document. He/she should be able to create an HTML representation of that document. He/she should also be able to assess the hurdles he/she faces in using TEI in his/her project and to decide on a proper course of action (e.g.: undertake project on his/her own, seek help in local institution or in wider TEI community, seek formal training). <br /> ==Audience== <br /> The document targets an academic (postgraduate, PhD, researcher, professor) that wants to start understanding and using the TEI: e.g. a graduate student who wants to make an edition of a book he/she is writing a thesis on. The document assumes someone working on his/her own, willing to learn something new, ready to work hard and to try various solutions. We assume someone that is reasonably comfortable using computers, but has no experience in programming and no previous knowledge of XML or HTML. <br /> * Secondarily, we should also include in our target audience people who are not themselves scholars but who are, or will be, working as encoders with a project. These may be undergraduates, editorial assistants, etc. We can assume that they are equally motivated with the academic readers, but they may not be familiar with the technical vocabulary of textual studies, bibliography, etc.<br /> <br /> ==Software==<br /> * Because we want to help people getting started, there is no way we can avoid talking about specific software programs. We must be specific. Neither can we avoid talking about commercial software, as oXygen is the environment of choice for so many people using TEI. <br /> * We should avoid the editors that are favoured by programmers and other technically oriented persons, such as emacs or vi. We want to minimise the learning effort expended on tools; what people should learn here is the TEI.<br /> * What we also want to avoid are expensive editors. We're writing this for people that are getting started. They are probably unwilling to invest a large amount of money.<br /> * If possible, we should avoid command-line tools. In fact, we want to recommend an editor that comes with validation and facilities for running a transformation. <br /> * We should try to discuss editors that work on the three major platforms. <br /> * The upshot of this is, for me: we discuss oXygen (inexpensive, works everywhere, very powerful, but not open source) and the XML Copy editor (Open source, works on Windows and Linux, reasonably powerful). Arianna suggests including jEdit.<br /> * All of these either come with an xslt processor (oXygen and XML Copy editor) or have a plugin for the purpose (jEdit).<br /> * The 'official' document will be based on oXygen. Other versions will be placed on the TEI wiki. <br /> <br /> ==Schema's and ODD==<br /> * From a logical point of view, for any project that uses the TEI, ODD is the starting point. ODD helps you make a schema and the schema helps you create and validate xml documents. From an educational point of view, however, it makes more sense to start with an XML transcription of a document, and introduce the schema after that. A schema, let alone ODD, makes no sense to someone who is not familiar with xml documents. Therefore, the idea of making a schema that fits your documents, and the way of making such a schema, is introduced only after the reader is familiar with modifying and validating XML documents. <br /> <br /> ==Contents==<br /> * As to TEI elements, this document stresses elementary things such as div, p, lg, l, hi, etc. As a TEI document must have a header, it will mention the header and provide some instruction for filling it, but it will focus on quickly attaining results, rather that on the administrative side of things.<br /> * As to schema's: throughout the getting started document, we use RELAX NG. We mention DTD's and W3C Schema's as an option, without going into their syntax. We explain RELAX using the XML syntax, and mention the existence of the compact syntax.<br /> * As to XSLT: the document will explain some of the concepts of XSLT (templates, XPATH, ...), and it will encourage readers to make some small changes to a toy stylesheet. It will discuss the stylesheets provided by the TEI and guide readers in making a simple customisation. It will not try to provide further instruction in XSLT.<br /> <br /> ==Style==<br /> We should try to be as clear and simple as possible. In a way, council members are not the best persons to write this document, as they may be too familiar with the technicalities to avoid terminology not immediately clear to beginners. We should be prepared to have this document reviewed by people less experienced in TEI and XML than we are. <br /> * Evidently, divisions of this document authored by non-native speakers of English should be reviewed by native speakers. <br /> <br /> ==Media use==<br /> * The document should include lots of screen shots. It may also contains links to video's of screen capture.</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4576 2008-09-12T10:52:28Z

<p>Peter Boot: </p> <hr /> <div>This is the outline of the 'Getting Started using TEI' document in the making. Chapter headings include the name of the person the chapter is currently assigned to. <br /> <br /> ===Introduction (Peter) ===<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> ====What this document does, and what it doesn't====<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ====Conventions used in this document====<br /> * How we label examples, program names, elements and attributes. 1p<br /> * How this document serves users on different platforms. 1p<br /> <br /> ===Should you use TEI?===<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ===Technical background===<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ===Overall structure of a TEI text===<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ===The rationale of declarative markup===<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ===Choosing and installing an editor===<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ===Load, modify, validate a complete ready-made document===<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ===Running stylesheets ===<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ===Getting this to work on sample of own text===<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ===Schema's===<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ===Where to go from here===<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ===Glossary===<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ===Literature===<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=Getting_Started&diff=4575 2008-09-12T10:48:20Z

<p>Peter Boot: first outline of getting started document</p> <hr /> <div>===Introduction===<br /> <br /> ===TEI: a very high-level overview===<br /> * TEI: a set of guidelines, but also a community. 4p<br /> * Why you would want to use TEI; explain the term 'encoding'; XML; what encoding entails; using an editor; validation; what you can then do with your document (transform it into other representations, have it searched; create selections). Possibilities for interchange and interoperability. 10p.<br /> <br /> <br /> ====What this document does, and what it doesn't====<br /> * One paragraph explaining that this getting started document is more elaborate than many other documents with a similar name: that is because learning TEI is similar in effort and in reward to things like learning a new language or mastering a musical instrument: 1p<br /> * Helps you get started, recognising that learning TEI is never going to be easy: 1p<br /> * It is not: a full course in using xml, in tei, in xslt, in html: 1p<br /> * Structure of the document. 2p<br /> * Intended readership: 1p<br /> * The reader is expected to have basic computer skills: create disk folders, move files, run programs, install programs, use unzip software. Not explain these, but just state you need the skills and suggest a way to acquire them. 2p.<br /> <br /> ====Conventions used in this document====<br /> * How we label examples, program names, elements and attributes. 1p<br /> * How this document serves users on different platforms. 1p<br /> <br /> ===Should you use TEI?===<br /> * Discuss nature of material, desired result, competence of encoder, available technical support, intellectual and practical benefits, effort to be expected, place of TEI in humanities computing: 12p<br /> <br /> ===Technical background===<br /> * XML: explain a few basics, then refer to gentle XML introduction: 5p<br /> * The web, web servers, html, browsers. One very simple HTML example, then point to other resources: 5p<br /> * Even gentler intro into creating html from xml using xslt (mention but not discuss: pdf creation and other output formats): 5 p's<br /> <br /> ===Overall structure of a TEI text===<br /> * Introduce sample document (without header), explain elements and attributes. 8p<br /> * Add header. 5p<br /> <br /> ===The rationale of declarative markup===<br /> * contrast declarative markup with wysiwyg editing: less susceptible to change, easily re-used in other contexts, unambiguous. 6p<br /> * abstract approach towards texts that befits the scholar as it helps understand textual phenomena: 3p<br /> * explain this again based on sample of drama markup. 4p<br /> <br /> ===Choosing and installing an editor===<br /> * Point out that XML is application independent. This implies you can select an editor suited to the task at hand. You don't select an editor for the document's lifetime. 2p<br /> * Discuss functions that an editor can handle: syntax highlighting, assisted entry, content completion, validation (dtd, w3c schema, relax ng), validation as you type, run xslt conversions, xslt debugging. Discuss source views: code view, wysiwyg view, tree view. Discussion illustrated with screen shots from multiple applications. 10 p<br /> * Discuss a number of editors: .... Mention, but discourage from, option of using plain text editor. 10 p<br /> <br /> ===Load, modify, validate a complete ready-made document===<br /> * This will be a document that we provide, together with a schema. Instructions for download. 2p<br /> * Show number of functions of editor: 18 p (because of multiple editors)<br /> ** different source views (maybe refer to oXygen video to explain editing in oXygen's author mode)<br /> ** different side views: model, outline, attributes<br /> ** find and replace<br /> ** etc...<br /> <br /> ===Running stylesheets ===<br /> * Explain what XSLT is and what it does. 2p<br /> * Installing XSLT processor, if not included in editor. 3p<br /> * Discuss a simple stylesheet to transform the sample document, and based on this a number of xslt instructions. 10p<br /> * Run the stylesheet and view the output. 2p<br /> * Do some simple modifications. 2p<br /> * Explain standard stylesheets. Download them. 4p<br /> * Customise standard stylesheets: first using Stylebear, then by actually overriding some templates. 5p<br /> * Running standard stylesheets. 1p<br /> <br /> ===Getting this to work on sample of own text===<br /> * Preparing text in XML vs. converting prepared text to XML: argue it is better to use structured text from scratch. 3p<br /> * Create an empty TEI document, using a template that we point to. 2p<br /> * Fill in the blanks in the header. 2p<br /> * Create a document snippet in the body. Validate. Generate HTML. 6p<br /> * Urge reader to put up both HTML and XML on web site: is motivating, helps discussion with others, .... 3p<br /> <br /> ===Schema's===<br /> * Explain the need for schema's that fit the texts. A few words about TEI conformance and TEI extensions. 4p<br /> * Explain modules, classes, macro's. 6p<br /> * Introducing ODD and Roma. Reference to 'Getting started with P5 ODD's. 6p<br /> * Setting up ODD, (de)selecting elements and attributes. 3p<br /> * Extension: creating a new element. Example: including tune indication for song. 3p<br /> * Add documentation, save customisation, create new schema and use it for validation. 5p<br /> <br /> ===Where to go from here===<br /> * What you probably need to do now: do document analysis, enter data, and create or modify a stylesheet that helps you display the data. 2p<br /> * Document analysis: study the appropriate portions of the Guidelines, perhaps sets of local TEI guidelines developed elsewhere, discuss this with others, get help. Urge asking for feedback. 3p<br /> * Enter data: if you have your texts in another format, it may help to learn some regular expressions: reference elsewhere. 2p<br /> * Create or modify stylesheet: serious work on xslt stylesheets is not for everyone. 2p<br /> * Places to look for tuition. 2p<br /> <br /> ===Glossary===<br /> ; ODD : One Document Does it all: document describing a TEI schema. See ...<br /> ; HTML : HyperText Markup Language, the language used to write web pages. <br /> ; etc...<br /> <br /> ===Literature===<br /> * References to other introductory material</div>

Peter Boot https://wiki.tei-c.org/index.php?title=User:Peter_Boot&diff=4255 2008-03-25T09:53:07Z

<p>Peter Boot: New page: More info [http://www.huygensinstituut.knaw.nl/index.php?option=com_content&amp;task=view&amp;id=97&amp;Itemid=57 here] or [http://peterboot.nl/ here]</p> <hr /> <div>More info [http://www.huygensinstituut.knaw.nl/index.php?option=com_content&amp;task=view&amp;id=97&amp;Itemid=57 here] or [http://peterboot.nl/ here]</div>

Peter Boot