[tei-council] comments on edw90

[Syd Bauman]

> >I'm confused. What then is the difference between tei.data.enumerated
> >and tei.data.token?
> No difference for one sense of "datatype", some difference for the
> other! The suggestion is to use tei.data.enumerated for cases where
> there is a <valList>, open or closed. But I am happy to go with
> tei.data.token for open/semi lists as well if this is felt to be
> clearer.

The idea from Paris was that a <valList>, whether closed, open, or
semi, is required for an attribute of type tei.data.token. I still
think that's fine.


> I would like to hear Sebastian's view on this -- he's back at work
> next week -- but I suspect he will say that this looks like rather
> recondite special-casing. After all, chances are that if you want to
> close the set of values you'll probably want to modify the TEI
> suggestions anyway.

While the former may be the case, I really hope we do a good enough
job of choosing values that at least for some attributes users would
be very happy just closing the list.


> Could we see a list of these?

Yes, in EDW90. The following all take advantage of W3C Schema facets
via RelaxNG parameters.
  tei.data.token
  tei.data.temporalExpression
  tei.data.duration
  tei.data.probability
  tei.data.numeric


> Again, I think we need to look at cases here. Suppose we started by
> just using the simplest (most generic) datatypes wherever possible,
> how many attributes would be seriously discommoded?

I've already looked at the cases. All of them. I've made suggestions
based on looking at them. Given that those suggestions were based on
the erroneous presumption that we could have code that would tighten
or loosen constraints of a datatype for a given attribute, quite a few
of them will need to be re-worked.


> I dont quite see what you're getting at here. We need to decide
> whether sex is an enumeration of possible values (possibly allowing
> people to use their own values), or a hardwired datatype like date
> values. My vote, fwiw, is for the former, but I'm open to
> discussion.

Now you've *really* lost me.

* Can people not change a datatype? (After all, it's just implemented
  as a macro.) If not, why not?

* If they can't change a datatype, what difference does it make
  whether the datatype is declared in terms of an <rng:data> or an
  <rng:choice> or a <tei:valList>?

* Why couldn't a hardwired datatype be an enumeration of possible
  values?

I think these two issues (whether an attribute type is abstracted to a
datatype or not, and whether it is expressed as an enumeration type,
some constraint on a string type, some W3C type, or some constrained
W3C type, etc.) are orthogonal.


> This is simply reiterating a decision we took at the Council meeting
> in Oxford, if I remember aright.

If you say so ... but which was the antecedent of "This"?


> >- token: do you mean "rng:token" or "xsd:token"?

> No idea. Please spell out the difference, and express your
> preference if any.

Difference is spelled out in EDW90. Basically xsd:token has one
additional (powerful) feature and one (minor) drawback over rng:token.
The additional feature is that further constraints can be applied via
facets. The drawback is that you must use a RelaxNG processor that
knows about W3C Schema datatypes. But since to process most the rest
of a TEI document, your RelaxNG processor is going to have to know
about W3C Schema datatypes anyway, I have a strong preference for
xsd:token. 


> I'm happy to stick with NCName

OK. If anyone has reason to prefer xsd:Name or xsd:NMTOKEN over
xsd:NCName for those attributes that used to be NMTOKEN (except for
unit= of <timeline>), speak now or forever hold your peace. (Well, at
least keep quiet about it for a few months.)


> I think it should be tei.data.token -- it can't have white space. It
> should be a single character in fact for any sensible kind of
> notation.

My first reaction was that this was unduly harsh, after all, it could
contain white-space in P4. But then I thought about it for a few
moments, and decided that any metrical notation that included
white-space could easily be re-worked without it. As above, if anyone
objects to tei.data.token (i.e., no white-space) for value= of
<metSym> (which was called <symbol> in P4), speak now.


> >Between half a dozen and a dozen attributes, I suspect. Most, if
> >not all, of which should be xsd:Name.
> Then let's go with that.

Errr ... didn't we just decide on xsd:NCName a few paragraphs above?


> >If we're going to use W3C datatypes, then at least in those cases
> >where W3C puts the unit in with the quantity (xsd:duration
> >explicitly, and the various date and time formats implicitly) we'd
> >have to do the same.

> Yes., but only if we chose to. We could say we will NEVER have
> attributes which combine in their value quantity+unit, or we could
> say we have some which do and some which dont, or we could say all
> quantities have the potential to include units. Again, a list of
> specific cases might help sharpen discussion and reach a decision.

Right, but my point was that the choice is inextricably linked to the
use of xsd:duration and xsd:[time-and-date-types]. If we make use of
those (and I can't really see not doing so at this point ... maybe
someday we could write a better datatype library, but it would be an
effort) then we can't choose "NEVER".


> ... Presumably if we define it as a macro, the user who only wants
> ever to express probability by means of a percentage can say so by
> redefining the macro.

My thoughts exactly.


> >I'm wondering if the concept of "positive integer or 0" is simple
> >enough that we don't need to bother creating a TEI datatype for it,
> >and could just use xsd:nonNegativeInteger directly when needed.
> 
> Fine by me.

Sounds good. Once again, if anyone objects ...


FYI, it will probably take me several days to completely update the
table to reflect these various changes (presuming no one objects), as
my wife will be away and I'll be playing Mr. Mom for a while.