July 2015 - Tei-council - lists.tei-c.org

bug report: @rend vs @rendition
by Syd Bauman 21 Jul '15

21 Jul '15

Sourceforge is currently down, so I'm posting this here in lieu of a bug report. Will transfer it to a ticket assigned to me later. --------- The remarks associated with att.global.rendition say Where both @rendition and @rend are supplied, the latter is understood to override or complement the former. This seems correct to me. The prose of section 1.3.1.1.3 "Rendition Indicators" says In the TEI scheme, it is possible to supply information about the appearance of elements within a source document in the following distinct ways: 1. One or more properties may be specified as the default for all elements of a given type, using the @render attribute to point to rendition elements ; 2. One or more properties may be specified for individual element occurrences, using the @rend attribute with any convenient set of one or more sequence-indeterminate tokens; 3. One or more properties may be specified for individual element occurrences, using the @rendition attribute to point to rendition elements; 4. One or more properties may be supplied explicitly for individual element occurrences, using the @style attribute. If the same property is specified in more than one of the above ways, the one with the highest number in the list above is understood to be applicable. At the very least, 2 & 3 should be reversed, and use of the @selector of <rendition> needs to be added to the list. But the idea that @rend has to be made of tokens (rather than a string) seems incorrect to me; and the idea that they must be "sequence indeterminate" is at best confusing, at worst hogwash. And why does @style override @rend? I think I'd prefer the reverse (but I'm not sure). Typo: extra space before semicolon in <item> #1.

4 9

question on <xenoData>
by Syd Bauman 14 Jul '15

14 Jul '15

First, <xenoData> should be a member of att.declarable. I think that's pretty much a no-brainer, but raise it here in case someone wants to object. But my next issue is at least non-obvious, if not controversial (and I hope it's not). How is a process to know whether the metadata supplied in <xenoData> applies to the TEI document or to the source thereof? Several possibilities jump to mind. 1) It doesn't. This is not our problem. Any project using <xenoData> will know what metadata they are using, so they'll figure it out just fine. 2) We add a new attribute to <xenoData>, @describes. Its possible values are "source" and "transcription" or some such. 3) We use a special @type (with values "source" and "transcription" or some such) for this, even though it's not quite right. 4) We add <xenoData> to att.typed and let projects come up with their own values of @type to assert this information. Maybe with suggested values (4a), maybe not (4b). 5) Instead of making <xenoData> a member of model.teiHeaderPart, and thus a younger sibling of <fileDesc>, we allow <xenoData> to occur as a child of <fileDesc> or as a child of <sourceDesc> (via membership in model.sourceDescPart). In the former case the metadata in <xenoData> is understood to apply to the TEI document; in the latter case the metadata in <xenoData> is understood to apply to the source from which the TEI document was derived. 6) Like (5), but leave <xenoData> as a member of model.teiHeaderPart instead of (6a) or in addition to (6b) a direct child of <fileDesc>. Personally, I'm leaning very strongly towards (2), (5), or (6a). That is, I think (1), (3), (4a), and (4b) are bad ideas, and prefer (6a) to (6b). That said, I'm open to thoughts, ideas, and suggestions.

8 36

feasibility and NVDL (and <xenoData>)
by syd＠paramedic.wwp.neu.edu 11 Jul '15

11 Jul '15

If the content model of <xenoData> is any.XML+, then the valid= of any <egXML> that contains a (valid) <xenoData> had better be "feasible" (or "false", I suppose), lest that <egXML> be flagged as having "error: unfinished element" by ./run-onvdl p5valid.nvdl v.xml If the content model of <xenoData> is any.XML*, then the valid= of the <egXML>s can be "true". This doesn't make sense to me, as the NVDL explicitly allows elements from the namespaces involved. But I'm guessing that before it checks the <egXML> itself for validity against the RELAX NG, it has removed elements from other namespaces (thus leaving an empty <egXML>). What is the difference between using "feasible" and "true" as far as processing is concerned? I.e., how does the feasibly-valid-checker (called p5.nvdl) know to apply the http://www.thaiopensource.com/validate/feasible to those <egXML>s flagged as "feasible" or "true", and how does the truly-valid-checker (called p5valid.nvdl) know not to? Must, of course, be that the latter is run against "v.xml", not p5.xml, but when and how is v.xml generated? For now I've checked in a version (to the P5-for-xenoData/ branch) with any.XML+ that uses "feasible" on its <egXML>s.

1 0

A quick question
by Martin Holmes 08 Jul '15

08 Jul '15

Can someone please remind me how to declare an attribute such that its content can be one or more of a set of values drawn from a fixed list? In other words, a closed valList, but allowing more than one item from the list. I'm sure I must have done this before, but I can't remember it. Cheers, Martin

2 1

readable xenoData
by Syd Bauman 04 Jul '15

04 Jul '15

I've put a complete copy of a P5-for-xenoData/ *with a built set of Guidelines and Exemplars* at http://paramedic.wwp.neu.edu/~syd/temp/TEI_Council/. So see, e.g. http://paramedic.wwp.neu.edu/~syd/temp/TEI_Council/P5-for-xenoData/Guidelin… (And someone let me know what the heck is the problem with the formatting -- it looks awful.) And use the schema at http://paramedic.wwp.neu.edu/~syd/temp/TEI_Council/P5-for-xenoData/Exemplar… to test it out.

3 5