[tei-council] Proposal <idno> coverage -SF 2493417

Daniel Paul O'Donnell daniel.odonnell at uleth.ca
Sun Jan 25 13:25:41 EST 2009


I've not been following this debate, but this exchange, and Peter's
comments does lead me to ask a question. Please forgive me if the
solution has already been discussed and dismissed.

As a middle ground, could not a solution be to use key point at a
different structure that contains the real pointer information? I.e. is
not Peter's complaint that there is too much information for @key? And
is a solution for that not to point to something where the multiple bits
of information can be collected?

Sebastian said that we'd need to go through the whole TEI looking for
similar issues. But it seems to me that we've already established a
principle of trying to offload complex information from textflow to
structures elsewhere in the document, i.e. in all our personography
work.

Again, sorry if this has been raised and dismissed.

On Sun, 2009-01-25 at 18:13 +0000, Lou Burnard wrote:
> I don't think anyone disagrees that the multiple <idno> solution is 
> better. But the @key value solution does do the job -- and doesn't 
> require any changes at all in the current system.
> 
> Peter Boot wrote:
> > Sebastian Rahtz schreef:
> >> in the short-term, I am unconvinced that @key cannot do the
> >> job for Laurent
> > 
> > Well, some reasons which haven't been mentioned up to now:
> > 
> > If the choice is between
> > 
> >    key="nldai:info:eu-repo/dai/nl/12456454
> >          openid:https://me.yahoo.com/johndoe61"
> > 
> > and
> > 
> >    <idno type="nldai">info:eu-repo/dai/nl/12456454</idno>
> >    <idno type="openid">https://me.yahoo.com/johndoe61</idno>
> > 
> > I would favour the idno element over the key attribute because
> > 
> > * the @type attribute's values can be very straightforwardly
> >   constricted to an known list of values, which is harder to
> >   do when multiple schemes and values are stored as part of a
> >   single text string (in the @key attribute);
> > * both the values and the schemes are straightforward to access
> >   in XSLT when using the <idno> solution;
> > * a rule-of-thumb in xml design is for me: if something has
> >   properties of its own (in this case, the identifier's scheme),
> >   it should be an element rather than an attribute.
> > 
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council



More information about the tei-council mailing list