[tei-council] datatype issues (part 1) continued,,,

[Syd Bauman]

> OK, I am perfectly happy to restrict the kind of gobbledegook permitted 
> for this datatype to a W3C-defined regular expression. That ought to fit 
> with most kinds of gobbledegook we can come up with!

Indeed, we can enjoy years of spewing gobbledegook (and validating
it) to our hearts' content.


> Is everyone happy with "regexp" as the name for it? how about
> "tei.data.pattern" ?

I don't think I care. On the one hand, I think tei.data.pattern is
less annoying as a name, but on the other the word "pattern" is
getting quite overloaded these days.


> We can probably distinguish cases where the name *must* conform to
> W3C rules about identifiers -- if it's the name of an element it
> obviously has to follow constraint on what an XML name can be. If
> however it's a name we've made up this is less obviously the case,
> and the only constraint we'd probably want to put on it is that it
> shouldnt contain white space (else we can't have tei.data.names).
> But do we really want two kinds of tei.data.name?

We've already done this. Those that *must* confrom to W3C rules about
identifiers are listed in the table as having xsd:Name as their
proposed type; those that don't are listed as having tei.data.token
as their proposed type.


> My proposal is yes, they [open & semi valLists] still have
> tei.data.enumerated.

Check. Seems to make sense. Note, though, that my earlier proposal to
use e.g. "met;real" as type= of <metDecl> won't work, as ";" is not a
permissible character in an xsd:Name, and all of the values in a
<valList> must be xsd:Names, as they are expressed in the ODD as the
ident= of <valItem>. (I'm concerned that if we changed ident= of
<valList> to be tei.data.[token,term,name] and thus allow bizarre
characters, Sebastian might go postal and spray the entire Council
with blue paint.)