[tei-council] comments on edw90
Syd_Bauman at Brown.edu
Sun Sep 4 14:59:26 EDT 2005
> >* tei.data.enumerated
> >* tei.data.code
> >* tei.data.key
> why is the second case not tei.data.pointer ?
Good question. In part because I was copying this datatype that we
already had. :-) But more to the point, as currently conceived,
tei.data.pointer is a generic URI. tei.data.code, on the other hand,
is a datatype for local constraint of tokens, that happens to use a
pointer to perform that task. That is, it permits the user to
constrain the set of values of an attribute from within the document
instance. So if a user wants to establish a set of roles for the
various participants in a language interaction, she can do this by
encoding the following <roleDef>s (yeah, I know, there's no such
thing) in the <teiHeader>:
or, better still
<roleDef xml:id="session-chair">The session chair, repsonsible ...
<roleDef xml:id="speaker">Paper presenter, not necessarily the
<roleDef xml:id="questioner">A member of the auidience who asked
Then in the paticipant group, a
can occur, and Schematron can easily check that the value of role= is
one of "#session-chair", "#speaker", or "#questioner". In some other
instance, even in the same project, we might find
<roleDef xml:id="conference-chair">One of the program committee
<roleDef xml:id="server">A server who works for the conference
hotel or the catering service they ...
<roleDef xml:id="diner">Hotel resteraunt patron ...
So just as something like
<gloss>The session chair, responsible for ... </gloss>
<gloss>Paper presenter, not necessarily the author ...</gloss>
<gloss>A member of the auidience who asked ...</gloss>
can be used from within the ODD to constrain the values, something
like the fictional <roleDef>s above can be used from within the
instance to constrain the values. The only reason for using a local
URI and xml:id= over an NCName and ident= is that it's more likely
generic software will be helpful in the former case. The only reason
for not using a local URI, IMHO, is to avoid that ugly "#".
If the datatype were a generic URI, Schematron could still validate
that an attribute pointed to a <roleDef>. It might even be able to
still validate that a bare name fragment identifier was used, and
that it matches the xml:id= of a <roleDef>.
> >Yes, that is the question we are currently discussing ... what
> >should the datatype of tei.data.key be, a URI or a name?
> >Personally, I'm inclined to stick with name. (I.e., that
> >tei.data.key boil down to xsd:Name.)
> I agree.
I'm just double-checking that I've understood you correctly. You are
in agreement that tei.data.key should boil down to an xsd:Name (as
opposed to merely agreeing that this is the question we are
> >OK. On the proposal to constrain the pointer in tei.data.code to be a
> >local pointer, ...
> I think it is a bad idea.
I suppose the reason I am shying away from full-blown URIs (i.e.,
prefer local URIs only, or co-reference with ident=) is that doing so
breaks away from the idea that the value of the attribute conveys
meaning itself, and that the pointing or co-referencing may be used
to provide constraint or to provide further information about the
semantics of the value.
Also, permitting any URI opens the can of worms I mentioned last
> >I didn't notice any other [places than <attRef>, <moduleRef>,
> ><specDesc>, and <memberOf> where key= is defined as a name], but I
> >didn't look that carefully. Either way, the point is that if we
> >change tei.data.key into a URI, we need to separate these
> >attributes out into yet a different datatype.
> I disagree. It is a name, not a pointer.
I don't understand with what you are disagreeing. In case there is
some confusion, let me reiterate the point. If we decide that the
datatype tei.data.key is a URI (which Lou is against, Syd is waffling
back & forth about, and about which no one else has issued an
opinion), then the key= attribute of
should not be declared using this datatype. (Which would be a bit
weird, as they're named "key".)
More information about the tei-council