[tei-council] datatypes: outstanding questions

Syd Bauman Syd_Bauman at Brown.edu
Sat Sep 24 11:38:23 EDT 2005


Very quick reply, as I have to leave in a few mins for flight to
Oxford.


> specDesc at atts:
>    list { xsd:NCName* } : I think list {tei.data.ident+}  wd be more 
>    consistent

Would be fine with me, but that "+" has to be a "*", as atts="" has
meaning. 


>    Syd marks all these as "NaAA" : but they are still all there and
>    need to be fixed if we want to retain this module

Right. "NaAA" really should be "NS2baAA" (not supposed to be an
attribute anymore :-)


> schemaSpec at start:
>    Syd proposes tei.data.idents: should be list {tei.data.ident+} for
>    consistency

In which case do we need tei.data.idents, or should we always just
use the RNG 'list' notation directly?


> tree at ord:
>    tei.data.truthValue | "partial" : shd be closed vallist, 
> tei.data.enumerated

It's fine with me, but I'm shocked that you'd suggest it. doesn't
putting "0", "1", "true" and "false" into an enumeration lose the
same information you lose by using "10:35" in a time?


> schemaSpec at namespace:
> elementSpec at ns:
>    Syd proposes xsd:anyURI : but is a namespace
>    necessarily a URI (and if it is, why not use
>    tei.data.pointer). suggest (new) tei.data.namespace mapping to ?

Yes, a namespace is necessarily an IRI (internationalized URI). From
the Namespaces in XML 1.1 spec:

  [Definition: An XML namespace is identified by an IRI reference;
   element and attribute names may be placed in an XML namespace
   using the mechanisms described in this specification. ]


> metSym at terminal:
> numeric at trunc:
> binary at value:
>    Syd suggests  xsd:boolean for these: I think they should all be
>    tei.data.truthValue (which should map to xsd:boolean; cases where 
> truthValue permits "unknown" shd be given different datatype)

Again, I don't see that the indirection gains us anything, but I
certainly don't object.


> timeline at interval:
> when at interval:
>    xsd:float { minInclusive = "0" } | xsd:token : rationalise to
>    tei.data.count and revise text (use null value for uncertain
>    interval size)

Can't: intervals don't have to be integers. (And remember, the only
token permitted was "unknown" or some such.) Could use
tei.data.numeric, but that permits all sorts of values (negative
numbers, scientific notation) that make no sense. (I suppose we could
use tei.data.numeric, and say in the prose that *any* negative value
indicates uncertainty.)


> handDesc at hands:
>    xsd:nonNegativeInteger | "many" : rationalise to tei.data.count and
>    remove "many" option.

I like the idea, but I'm worried that the reason P4 permitted the
vague term(s?) is because manuscript describes do not want to or
cannot accurately count the number of hands. Matthew?


> sense at level:
>    xsd:unsignedShort : shd be tei.data.count

Yup.


> alt at wScale:
> altGrp at wScale:
>    Syd says [should be dropped completely] : i agree, assuming that we
>    agree on using either 0..1 or 0..100 (but not either) to express
>    probabilities. These elements need a lot of tidying up.

It can (and should) be dropped completely if we allow either, is long
as they can be differentiated by syntax, e.g., appending "%" to the
0..100 case.


> %tei.pointerGroup at targFunc:
>    list { tei.data.ident, tei.data.idents } : I agree that this should
>    be handled in the same way as targets attribute, but its components
>    are tei.data.name not tei.data.ident -- they are arbitrary names,
>    not XML identifiers

OK w/ me. I think I was just copying the description.


Gotta go ...




More information about the tei-council mailing list