#530 a new ODD element for pointing at datatypes

[Sebastian Rahtz]

We have two sorts of macros in the TEI, for datatypes (eg data.sex, data.xText etc) and for
patterns (macro.paraContent). These are rather different beasts, differentiated by their "type" attribute. In the Pure ODD reformulation of the content model, it seems like a good time to give the datatypes their own high level <dataSpec> and <dataRef> elements, allowing us to think about deprecating the pattern macros which can confuse readers.

[Lou Burnard]

Agreed that this is a good idea. Will add to my todolist for pure odd

[Sebastian Rahtz]

I note out that there is still the problem of what notation to use inside <dataSpec> to indicate that we want W3C integers or ISO languages. e.g. needs a copy of RELAX NG's <data> element, and need to decide whether and now it supports the full power of that.

[James Cummings]

Assigning to LB at f2f raleigh 2014-11-17

[Lou Burnard]

Attached (a) specification for dataNode (b) HTML report on mapping current datatype macros

[Lou Burnard]

Here's an informal summary of what is now being proposed

• A <datatype> as used in an <attDef> contains one or more <dataRef /> elements, under control of <alternate>, <sequence>, @minOccurs etc. (or a valList )
• The target of a <dataRef>, supplied by its @key, is a <dataSpec>, which contains the usual ODD richness (<desc>, <exemplum> etc.) and a <content> element, which contains
• one or more <dataNode> elements, under control of <alternate>, <sequence>, @minOccurs etc., or a <valList>
• Each <dataNode> references a primitive datatype in some schema language and has attributes
• @name gives the name of the primitive datatype (e.g. @name="float")
• @source gives the URI of the library in which this datatype is defined (in its absence, we assume we are talking http://www.w3.org/2001/XMLSchema-datatypes )
• @restrict supplies an additional restriction on acceptable values for the datatype expressed as a regexp

The trouble with @restrict is that there may be some restrictions you might want that can't be expressed as a regexp. I haven't found any yet,

Attached: a list of all existing TEI datatypes and their purified forms

[Lou Burnard]

Here's a revised summary of what is now being proposed

• A <datatype> as used in an <attDef> contains one or more <dataRef /> elements, under control of <alternate>, <sequence>, @minOccurs etc. (or a valList )
• The target of a <dataRef> is supplied using one of @key, @name or @ref.
• In the first case, the @key points to a TEI-defined a <dataSpec>, which contains the usual ODD richness (<desc>, <exemplum> etc.) and a <content> element, which contains
• one or more <dataRef> elements, under control of <alternate>, <sequence>, @minOccurs etc., or a <valList>
• In the second case, @name specifies a primitive datatype name as defined in http://www.w3.org/2001/XMLSchema-datatypes
• In the third case, @ref supplies a pointer to a datatype in some other schema language
• The attribute @restriction may be used to specify additional restrictions on acceptable values for the datatype. It is expressed as a regexp.

[Sebastian Rahtz]

so do you add a restriction that dataRef inside dataSpec can only use @name?

[Lou Burnard]

Interesting question. This is presumably to prevent things recursing for ever?
I am sure however someone will want to have chained dataSpecs, so maybe the rule should be that such a chain must finish with a @name (or a @ref)

[Sebastian Rahtz]

yes, thats obviously a necessary informal rule, but i dont know how to enforce it.

something bothersome about the two attributes doing different things. TBH, I'd rather see a new primitive inside dataSpec doing the job of dataRef/@name. But I can see the counter argument too. maybe @name is insufficiently meaningful? could you have @base?

[Lou Burnard]

Why do you think they are doing different things? All three are (varieties of) pointes, surely?