[tei-council] Datatypes.... continued

[Syd Bauman]

Lou Burnard writes:

> >>1. add at place 
> >>   addSpan at place
> >>           -->  tei.data.enumerated
> >What do you propose the value list be? The list{} method proposed
> >permits things like "opposite top left" (which is also permitted in
> >P4). 
> I have no particular proposal. Any list I came up with only be
> advisory anyway.

The point I was trying to make is that if we want to mimic the P4
recommendations we will find it very hard to use tei.data.enumerated.
If we don't want to mimic the syntax P4 used, fine, but it will be
awfully hard to come up with a system that permits the various
combinations P4 allowed. I'll wonder aloud if it would be difficult
to add the capability to <valList> to permit one or more, rather than
just one, from the list.


> > [ met/real/rhyme list for type= of <metDecl> ]
> so here;s a case where an enumeration is both possible and
> desirable. good!

Yes, but it doesn't scale well at all.


> >>2. tei.pointerGroup at domains  
> >>          -->  tei.data.pointers
> >I don't really see it as a plus to permit values that the prose says
> >are invalid just to say we used a datatype directly. The EDW90
> >recommendation matches the prose perfectly. (It is
> >  list { tei.data.pointer, tei.data.pointers }
> >.)
> >On the other hand, ... [could use Schematron]
> Actually, I wonder if it might not be better to rethink this
> attribute into two?

I don't follow you. I really don't like how this attribute and its
cousins targType= and targets= work, so I'm all ears if you have a
different recommendation.


> >>3. schemaSpec at start
> >>    specDesc at atts   
> >>         --> tei.data.names
> >Again, why use a lax constraint when the proper one is readily
> >available just to say you used a datatype? ...
> Is this another instance of the particular problem that we;re using
> "name" sometimes to mean a NMTOKEN and sometimes not?

I don't see how. And I don't think I've ever used "name" to mean
NMTOKEN (or NCName or Name, for that matter).


> >>4. date at precision
> >>       --> tei.data.certainty
> > ...
> I can't remember who suggested having "precision" as an explicit
> attribute on date. It does seem to overlap with the value
> attribute. Unless anyone wants to fight to the death for it, I
> propose we remove it.

Fight to the death? I wouldn't even trade a stale slice of bread for
it. Until someone sits down and really thinks through representations
of precision, accuracy, and certainty, I think we should nuke it.


> >>9.   tei.declarable at default
> >>     tei.identifiable at predeclare
> >>     metSym at terminal
> >>     numeric at trunc
> >>     binary at value                  
> >>        --> are all xsd:boolean (so "unknown" not allowed) ;
> >>could just be tei.data.truthValue with extra rule
> >
> >Could be. And at one point in the history of that EDW90 table,
> >they were. But a week or two ago we agreed to go directly with
> >xsd:boolean.
> 
> So we either have to have a pair of datatypes, one permitting
> "unknown" and one not, or we have to have an additional rule to
> exclude "unknown" in cases where it makes no sense, like these.

Or we could use "tei.data.truthValue" for attribute values for which
"true", "false", and "unknown" all make sense, and "xsd:boolean"
directly for the above, where only "true" and "false" make sense. As
was pointed out before, if you need TEI prose to explain what 'true'
and 'false' mean, you probably shouldn't be encoding texts anyway.


> >>10.  timeline at interval
> >>       when at interval   
> >>       --> tei.data.numeric | -1  (or think of a better way of
> >>           doing the -1)
> >
> >a) We'd go back to needing unit= (I'm not saying this is so horrible,
> >   just want to make sure everyone understands the implications) ...
> > ...
> >Thus, I am now leaning towards
> >   xsd:long { minInclusive = "0" }  |  xsd:token "unknown"
> 
> where did the "unknown" come from? I think it shd remain
> tei.data.numeric, but with the constraint that it can't be smaller
> than -1

My apologies, I thought it was clear. In P4 an interval is either
a) a positive number which, when combined with the value of units=,
   gives you the interval; or
b) the special value '0' meaning that all the intervals are evenly
   spaced, but the size of the intervals is not known; or
c) the special value -1 indicating uncertainty about all the
   intervals in the timeline
My proposal above was intended to use "unknown" instead of "-1"; why
use a funny coded numerical value? It might make perfect sense to use
another keyword for (b), and use "minExclusive" instead of
"minInclusive". Yes, that would be better, if we could just come up
with a good keyword.

I'm not sure we can actually constrain a TEI datatype as you
suggested, but if we can and do use 
   tei.data.numeric { minInclusive = "-1" }
we end up permitting all sorts of values *between* -1 and 0 for which
we have no definition. (Many a good elisp program would solve this by
just using tei.data.numeric, mapping "0" to (b), and any negative
value at all to (c).)