[tei-council] comments on edw90

[Syd Bauman]

> >* the value is from a list specified in the DTD (e.g., status= of
> >  <availability>)
> >
> >* the value is an IDREF to something (which has an id=) specified in
> >  the document instance (e.g., who= of <sp> or resp= of <add>)
> >
> >* the value is a key into some (ostensibly external, but Lou correctly
> >  points out that, especially in the P5 world, it may well be in the
> >  document instance) resource (e.g., key= of <name>)
> > ...
> I agree. What are the datatypes which, in P5, should correspond
> with each of these three cases?

* tei.data.enumerated
* tei.data.code
* tei.data.key


> That depends on what the datatype for "key" is. If it is a URIref,
> yes. If it is just a xsd:name, then you can't do that without
> modifying the ODD (which of course is no big deal)

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 think we should use a pointer for the second class
> [tei.data.code] and xsd:name for the last [tei.data.key].

OK. On the proposal to constrain the pointer in tei.data.code to be a
local pointer, do you think it is
a. a bad idea
b. a good idea
c. you're indifferent
d. a bad idea for TEI to enforce it, but the Guidelines should mention
   that a project may wish to add this restriction locally, and
   perhaps even describe how
e. the TEI should enforce it, and the Guidelines should mention that
   a project may which to remove this constraint, and perhaps even
   describe how
f. the Princeton Band

Personally, I am leaning towards (b) or (d). The problem with
permitting a tei.data.code attribute to point outside the current
document is that it opens a bit of a can of worms as to what it
points at. E.g., if new= of <handShift> is supposed to point to a
<hand> inside a //TEI/teiHeader/profileDesc/handList, great. But if
you're putting that <hand> in an external document, what goes inside
the <text> of that external document?


> >Note that, if I understand correctly, the key= of <attRef>,
> ><moduleRef>, <specDesc>, and <memberOf> is currently defined as
> >being a name, and is tied to being one processing chain. I.e.,
> >using a URI here would break things.
> 
> Also elsewhere, probably.

I didn't notice any others, 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.


> See comment above. I dont think we should add special purpose rules
> of this kind.

Which comment above? Doesn't matter. I think I was on drugs when I
suggested it. It's a hack, and as such the TEI should not be
recommending it. Suggestion withdrawn.


> I dont pretend to understand what you're getting at here,. but in
> any case it seems a bit beyond our current remit.

Just that we should not kiss off the concept of tei.data.code, i.e.
of allowing a user to constrain an attribute's value[1], and perhaps
provide some semantics, by making it refer to something in the
current instance (or potentially elsewhere). It's an important idea.

Note
----
[1] And yes, the constraint is *not* enforced by your schema
    validation process, but rather some separate link-checking
    process.