>> http://namespace.tei-c.org > interesting idea. any one else like that? Yeah, that's good. I like it. S
Greetings, TEI community! We are glad to announce that Syntext Serna, the XSL-on-the-fly rendering XML editor, now also supports TEI! We have unveiled the pre-release TEI support update, and are looking forward to your comments. Serna renders TEI documents with XSL stylesheets a lot similarly to the well-known Sebastian Rahtz' stylesheets. Serna is available for Windows & Linux. See: http://www.syntext.com/products/serna/index.htm It is worthy mentioning that Serna is available for academic users for special prices! Fully-functional free trial is available at: http://cms.syntext.com/trial-request Please make sure you also download the TEI update zip package. Unzip it in Serna installation directory (see README file for details). Please feel free to e-mail any comments and suggestions for improvements to serna-users <at> syntext.com mailing list. We are especially interested to hear from you: - TEI stylesheet improvements suggestions. - What widely used TEI-based DTDs (besides TEI Lite) should be included to Serna out-of-the box. - Suggestions for usability enhancements.(Continue reading)
>What else is new? Well, the inner machinery is changing a lot. If you >have at last managed to get your head around the way that TEI P1 to P4 >used parameter entities and other devious tricks to support its >modularity and extensibility -- we salute you! If you're one of those >who thought you'd rather wait for something a bit easier to understand >than the current chapters on those topics -- you were right! So what are the mechanisms for customization in P5? In ways are they easier to work with? Greg Murray Digital Library Production Services University of Virginia Library
> > So what are the mechanisms for customization in P5? In ways are they easier > to work with? as currently set up (a caveat in case it all goes wrong), all the TEI modules are separate RelaxNG schemas. The normal method of working, I believe, will be to make a project-specific schema file, which loads the base TEI, the modules you want, and any overrides. So instead of using the DOCTYPE subset in each XML file, or having a baked pizza, you'll have your own local schema with your own view of the TEI. In your customizations you might have things like: - redefining or limiting datatypes of attributes - extending TEI element classes with new entities - changing names of elements - defining the allowed values for attributes like "rend" or "type" - changing element content datamodels and so on. most of these are not really new, but (so far as I can tell) people find them fairly difficult to use in XML world. I believe the Schema equivalents will be a lot easier to understand Sebastian
I promised I would provide some more detailed discussion of what's
changing in P5. Here's an example of something that we're not 100% sure
about yet.
P1-4 have a number of elements which were sometimes called "mirror tags"
-- partly because they came in pairs: for example <sic> and <corr>. As
well as being paired, these elements have the intriguing property that
you can put content into them as attributes, in other words that you can say
<sic corr="wibble wibble">wobble</sic>
or
<corr sic="wobble">wibble wibble</corr>
This seemed quite a good idea at the time, and is certainly quite
heavily used. For one-word corrections like the above, it's simpler than
the full blown app.crit. methods, and seems to come with less
text-critical baggage. It's not a solution which scales well -- in the
sense that you couldn't use it to record lengthy passages of variation
-- and it's not always clear which of a pair of mirror tags should be
preferred, or what it means if you have both. And it doesn't scale well
in the other sense either: it's not an expandable kind of mechanism: for
each new kind of editorial intervention to be distinguished from others,
you have to find not just one name but two!
But the reason for feeling that this mechanism really has to go is none
of the above. Its really fatal flaw is that it allows (nay, requires)
you to store text content as attribute value. Never a good idea, this
has become a decidedly bad one in the unicodified world of XML. Why?
because things that look like tags within attribute values are not in
fact interpreted as such. No XML processor will see anything
approaching an occurrence of the <c> element in the following:
(Continue reading)
Following Matt Zimmerman's launch of one SIG about presentation issues, here comes the next result from Nancy, viz the TEI Authoring SIG. At the members meeting, we had a largeish group discussion, and it was agreed to set up two separate (but related) groups. I volunteered to coordinate the Authoring activity. The aim of the TEI Special Interest Group on Authoring is to develop good practice in using the TEI markup to write modern office-type documents (reports, web pages, articles etc). This covers: * which elements to use from existing modules, and for what * which new elements or attributes are needed * ideas about incorporating other XML languages (MathML, SVG, Docbook etc) * suitable authoring tools The aim is to generate: * examples of TEI subsets and extensions used for authoring * guidelines on for authors thinking of using the TEI * suggestions to the TEI Technical Council about which new elements are needed in P5 to support this area The SIG's work will be on http://www.tei-c.org/Activities/SIG/Authoring/, and the current web site editor is sebastian.rahtz <at> computing-services.oxford.ac.uk If you are interested in this, please join the list, by sending a message to(Continue reading)
On Mon, 1 Dec 2003, Sebastian Rahtz wrote: > as currently set up (a caveat in case it all goes wrong), all the > TEI modules are separate RelaxNG schemas. The normal method of working, > I believe, will be to make a project-specific schema file, which loads > the base TEI, the modules you want, and any overrides. So instead of > using the DOCTYPE subset in each XML file, or having a baked pizza, > you'll have your own local schema with your own view of the TEI. > In your customizations you might have things like: > > - redefining or limiting datatypes of attributes > - extending TEI element classes with new entities > - changing names of elements > - defining the allowed values for attributes like "rend" or "type" > - changing element content datamodels > > and so on. > > most of these are not really new, but (so far as I can tell) > people find them fairly difficult to use in XML world. I believe > the Schema equivalents will be a lot easier to understand I look forward to this and think it will be a lot easier for people to understand - or at least people like myself who are more comfortable in XML than SGML technologies. Could I ask (again displaying my ignorance) how this will affect the definitions in chapter 28 (Conformance)? There is a note on this chapter stating that: "The recommendations in this chapter are likely to be substantially revised at the next release." I believe all the(Continue reading)
On Tue, 2003-12-02 at 10:12, James Cummings wrote: > Could I ask (again displaying my ignorance) how this will affect > the definitions in chapter 28 (Conformance)? I think that chapter 28 will need a complete re-write, and some careful thought about what conformance means. No small task. > Maybe I'm just being pedantic, but it seems a distinct change in > approach that instead of using an extensions file that is included > by the DTD, the local processing format instead includes the TEI > into its own view. I hasten to say that this approach is what I believe is the best way to work, and is not based on any consultation. We should discuss it here. Just to muddy the waters, P5 will (unless proved impossible, or voted down) also produce modular DTDs as before, so the old method of working will still be available. > The end result is the same, but since many people > (including myself) will find this much easier to do and so will include > many more (namespaced?) local additions and modifications is it going > to lead to the gradual dissipation of the TEI as an interchange format? I don't see why. I think many people at present just hack the DTDs by hand, which is even worse. The easier we make it to do extensions in a controlled and readable way, the better off we'll be. My view is that the correct use of the local schema is very often to(Continue reading)
TEI folk, Some time back I posted a note about XMLStarlet, a package of command-line programs for manipulating XML files in many ways. I have found it invaluable in working with XML file collections. If you run OS X, there is now a Fink package available, which will make installation much easier (getting the compile options right was a chore). Package description: xmlstarlet-0.6.0-11: Command-line XML manipulation tool XMLStarlet is a set of command line utilities which can be used to transform, query, validate, and edit XML documents and files using simple set of shell commands in similar way it is done for plain text files using UNIX grep, sed, awk, diff, patch, join, etc commands. . Web site: http://xmlstar.sourceforge.net/ . Maintainer: Daniel Macks <dmacks <at> netspace.org> This is the next-to-latest release; the maintainer notes that packaging 0.7 has to wait until he has access to some macros that aren't defined in the Fink 10.2 tree. David -- David Sewell, Editorial and Technical Manager Electronic Imprint, The University of Virginia Press PO Box 400318, Charlottesville, VA 22904-4318 USA Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903(Continue reading)
I ranted a while back[1] on why I thought that PCDATA-only corrective mechanisms should co-exist with the element-selection oriented version now proposed as <choose>. As I see it, we could offer corrective/alignment mechanisms at three levels: the full text critical, the multiple-option <choose> variant, and (PCDATA-only) simple character corrections. The first of these is a different issue; for the others, here's my suggestion: We keep all the existing tag names, such as <corr>, <reg>, etc (as would appear to be shown in Lous' example), but we use the Power of Schema Languages to define them differently depending on context. When they do not occur as children of a <choose> element, they are permitted the <at> reg, <at> sic, etc. attributes, but (and this is important) the actual element content is limited to PCDATA only. Within <choose> they may hold the usual mixed content, but the <at> sic, etc attributes are prohibited. By restricting the content of 'naked' <corr> et al to PCDATA, we are now clearly showing (and will reflect with equally forceful language in the guidelines) that outside of a <choose> element these can only be used for character corrections. If I desire either a multiplicity of options, or to give elements within the options, then I must wrap it up it in <choose>. This retains the minimal-coding simple character correction version which I still staunchly defend, allows the options version, and does not introduce a raft of new element names. I think this is good. On a slightly variant topic, can I quote a SIG list where it was stated (by his Louness no less): "One of the Good Decisions made in the early days of the TEI was that it was not going to mess with software development: you cannot at once claim to be developing a software-independent encoding scheme and also a specific piece(Continue reading)
RSS Feedand
155 | |
|---|---|
129 | |
184 | |
268 | |
206 | |
188 | |
117 | |
69 | |
82 | |
160 | |
201 | |
68 | |
139 | |
191 | |
332 | |
129 | |
146 | |
79 | |
216 | |
154 | |
167 | |
321 | |
94 | |
174 | |
226 | |
169 | |
166 | |
144 | |
97 | |
57 | |
135 | |
145 | |
166 | |
110 | |
78 | |
117 | |
44 | |
116 | |
401 | |
191 | |
238 | |
174 | |
117 | |
106 | |
146 | |
70 | |
122 | |
123 | |
69 | |
125 | |
156 | |
81 | |
167 | |
108 | |
129 | |
152 | |
74 | |
58 | |
79 | |
58 | |
114 | |
170 | |
119 | |
160 | |
139 | |
122 | |
149 | |
188 | |
84 | |
66 | |
174 | |
45 | |
141 | |
115 | |
142 | |
156 | |
137 | |
98 | |
133 | |
84 | |
84 | |
114 | |
59 | |
138 | |
187 | |
108 | |
121 | |
156 | |
97 | |
44 | |
67 | |
57 | |
84 | |
93 | |
110 | |
92 | |
86 | |
93 | |
115 | |
162 | |
218 | |
62 | |
128 | |
58 | |
60 | |
37 | |
66 | |
96 | |
89 | |
84 | |
138 | |
123 | |
121 | |
112 | |
87 | |
222 | |
100 | |
97 | |
74 | |
65 | |
51 | |
69 | |
72 |
