on spec grp 4, coded values (was "Re: [tei-council] datatypes")

[Sebastian Rahtz]

Syd Bauman wrote:

>  I think there are several good reasons to restrict these kinds of
>  references to local pointers.
>
>  - It mimics what P4 had.
>  
>
that's not one of our design goals, though

>  - It provides a system (as did ID/IDREF) where the attribute value
>    itself may be used as a code for a useful semantic distinction
>    (thus the name). E.g., new= and old= of <handShift> -- the real
>    details are provided by the <hand> to which they point, but
>    mnemonic values like "#Scribe1brown" and "#Scribe2red" can convey
>    a lot of meaning by themselves, or at least be easy for humans to
>    associate with the appropriate <hand>.
>  
>
I dont get this. why are local pointers more readable
than remote ones?

>  - By changing the values of the xml:id= attributes of the elements
>    pointed at (e.g., <hand>), the encoder gets to create the
>    vocabulary used.
>  
>
well, if they want to work that way, they can, no?

>    If we stick to local pointers, we can define the place or places
>    (likely in the TEI header) to where each tei.data.code attribute
>    is supposed to point, document it accordingly, and perhaps write
>    a Schematron rule to verify that it does so.
>  
>
there is some strength in this, I agree.  but as Christian says,
its not always so obvious what "local" means

>    If we permit any pointer, documentation where these things point
>    becomes somewhat harder. E.g., if the new= of <handShift> points
>    to an external file, does it still need to point at a <tei:hand>?
>  
>
fair point. usage will dictate the pattern

>    rewrite the prose so that it is clear that the <hand> in one TEI
>    document may well be documenting the handwriting in another.
>  
>
sadly true :-}

>* tei.data.key: the change is from 'xsd:token' to 'rng:string'. I
>  think it should be left as 'xsd:token' just for consistency. There
>  is no difference in validation at all (since there are no
>  enumerated values).
>  
>
you cannot predict what a database key looks like.
It is not acceptable to say you can only interact with
external systems which key things use a "xsd:token" datatype




-- 
Sebastian Rahtz      
Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

OSS Watch: JISC Open Source Advisory Service
http://www.oss-watch.ac.uk