Hi Raff, That was quick! Looks good too. The only comments I have are minor, mainly native-speaker quibbles. In this sentence: ID attributes must be unique within a single document, and ID values must begin with a letter. I think it should be <att>xml:id</att> rather than "ID", shouldn't it? "derived by textual structure" -- I think "derived from the text structure" might read a bit better. "extra-textual contingencies such as project and file management matters" -- I think I'd replace "matters" with "concerns". "...the attribute used, the elements which can bear standard reference identifiers, and the method for constructing standard reference identifiers, should all be declared in the header..." -- I think the comma after the second "identifiers" should go (no comma between subject and predicate in English). The phrase "bit of text" seems a bit informal -- how about "section of the text"? In the description of typed-path and untyped-path identifiers, I think it would be a good idea to point out that such identifiers, being mechanically derived, can -- and in fact, for accuracy, probably should -- be generated algorithmically, even if later they end up being maintained manually through changes to the text. The paragraph at line 3260 seems to be partly a duplicate of the one starting at 3173. "it is left to the encoders to make a decision" -- I would delete "the" to make it generic. "Note that XSLT's function generate-id() only guaranteed identifier unique to the document being processed." -- "guaranteed" should be "guarantees". "The Guidelines only require that <att>xml:id</att> attributes are unique in the document for XML well-formedness. However..." -- I would rephrase: "XML well-formedness requires only that xml:id attributes be unique within a single document. However.." Hope this helps, and hope you're having a safe trip home. Martin On 2015-05-30 06:47 PM, Raffaele Viglianti wrote:
I've expanded a bit the Core Elements chapter section 3.10.2 to list some examples of usage for xml:id. Please review for content and grammar, starting from this div to the end of the parent section: https://github.com/raffazizzi/TEI-Guidelines/blob/master/P5/Source/Guideline...
I also didn't add anything about check digits, because I admit --and I tried-- I can't understand how they work :) Maybe Peter could add a sentence or two?
Thanks! Raff
On Mon, Feb 23, 2015 at 12:42 PM, Fabio Ciotti
wrote: Sorry if I jump in this interesting discussion late, it is a busy period :(
In general I do not think TEI (at least in the Guidelines) should recommend one or another way of creating IDs since there are pros and cons in each of the possible choices. I think this is a typical user or project specific problem, and I believe we should not interfere with user preferences if and when they do not goes against TEI semantics (as for the syntax of IDs).
We can of course have an exemplification and even a discussion of possible approaches, but it must be clear that any solution is ok as far as TEI is concerned. The same for the granularity of the IDs. I think that TEI should still follow the regulatory idea of being as far as possible independent from specific tradition, theories and methodologies that shapes the pragmatics (and rethoric) of text encoding.
Maybe customization like TEI simple could mandate one syntax or another, since its objective is precisely that of giving a more constrained tag set.
Anyway, it seems to me that generally the majority of the council would prefer to have at least some examples of ID usage on the guidelines. I would still refrain from calling them "recommendations" because of the variety of valid approaches that people are suggesting. But we can still offer two or three suggestions based on style and personal preference rather than actual effectiveness of a strategy, because it's too dependent on extra-textual contingencies. Agreed.
With the caveat I expressed above, agreed
We should probably look to see if any other XML projects have such recommendations too (DocBook, DITA, etc.).
yes, but again we must keep in mind that TEI has quite different rationales, principles and scope than DocBook, and a fortiori DITA.
F -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived