[tei-council] comments on edw90

[Syd Bauman]

> >* 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>:

  <roleDef xml:id="session-chair"/>
  <roleDef xml:id="speaker"/>
  <roleDef xml:id="questioner"/>

or, better still

  <roleDef xml:id="session-chair">The session chair, repsonsible ...
  <roleDef xml:id="speaker">Paper presenter, not necessarily the
                            author ...
  <roleDef xml:id="questioner">A member of the auidience who asked

Then in the paticipant group, a
  <person role="#speaker">...
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
                                     co-chairs ... 
  <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

  <valList type="closed">
    <valItem ident="session-chair">
      <gloss>The session chair, responsible for ... </gloss>
    </valItem>
    <valItem ident="speaker">
      <gloss>Paper presenter, not necessarily the author ...</gloss>
    </valItem>
    <valItem ident="questioner">
      <gloss>A member of the auidience who asked ...</gloss>
    </valItem>
  </valList>

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
discussing). 


> >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
time.


> >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
  <attRef>
  <moduleRef>
  <specDesc>
  <memberOf>
should not be declared using this datatype. (Which would be a bit
weird, as they're named "key".)