View source for ODD-dev

[[Category:Suggestions]]

This page has been set up to record underlying problems with the TEI [[ODD]] language and look at methods for improving them.


=== Problem: Module inter-dependency ===
* '''Desc:''' In some cases elements in one TEI module (A) require that another TEI module (B) is loaded because the content models of an element in A directly requires something that is defined in B (e.g. a class or element) but no method exists indicate this module inter-dependency.  This sort of dependency can, of course, happen inside a single module as well with a content model explicitly referring to a particular element which is then removed.  Some concept of dependency of references needs to be implemented.
* '''Suggested solutions:'''  
This is largely mitigated by ensuring that content models reference model classes rather than explicit elements. A further prosecution of class warfare might therefore be useful.
* '''Points for discussion:'''
** None so far

=== Problem: Subclasses ===
* '''Desc:''' The ability to add subclass membership to an element to, for example, grant it some extra attributes in a particular location. e.g. “I want the head inside figure to be the real <tt>&lt;tei:head></tt> element but have it be a member of <tt>att.mySpecialAttributes</tt> to give it some extra attributes, but only when it is inside <tt>&lt;figure></tt>”. This may also relate to Per-element attribute-based customisation in specific circumstances mentioned below.
* '''Suggested solutions:''' none so far
* '''Points for discussion:'''
# I ([[User:Syd|Syd]]) am under the impression that the problem cannot occur exactly as described. If you add attributes to the <tt>&lt;head></tt> element (whether directly or by adding it to the class <tt>att.mySpecialAttributes</tt>), it will not validate against <tt>tei_all</tt>, and has to be placed in another namespace. I.e., it ''cannot'' be <tt>&lt;tei:head></tt>.
***# '''Reply:''' Perhaps poorly phrased in the description. How about we reverse it: let's say you want to remove @n from <tt>&lt;figure></tt> globally, but then allow it back when inside <tt>&lt;figure></tt>.  Obviously you can test that with schematron, but not (I think) simply by adding <tt>&lt;figure></tt> to a new attribute class.  [[User:James|James]] 10:23, 1 September 2009 (EDT)

# That said, the desire to have special attributes on <tt>&lt;my:head></tt> when it is a child of <tt>&lt;figure></tt> and not otherwise is a very reasonable one.
# RELAX NG permits co-occurrence constraints like this, but ODD and DTDs do not. W3C Schema 1.0 does not. Rumor has it that XSD 1.1 will, but I haven't looked carefully.
# As it stands it would be very reasonable to add the attributes to <tt>&lt;my:head></tt> in the ODD tagdoc, and then add a “don't use these attributes unless a child of <tt>&lt;figure></tt>” as a <tt>&lt;constraintSpec></tt>, i.e., in Schematron.

It seems to me that this is very much in schematron country, because of the element content/context dependency.

=== Problem: Per-element attribute-based customisation ===
* '''Desc:''' The ability to customise the desc, valList, and other aspects of an attribute inherited from a class on a per-element basis.  For example giving different suggested values for @type on an element, or a more specific description of an attribute when used on a certain element.
* '''Suggested solutions:''' none so far
* '''Points for discussion:'''
** None so far



=== Problem: attribute/content interdependency ===
* '''Desc:''' Attributes and content interdependency means that you can have either attribute or content but not both.
* '''Suggested solutions:''' none so far
* '''Points for discussion:'''
** None so far



=== Problem: Chaining of ODDs ===
* '''Desc:''' ODD should be able to be based not on the full TEI but on another ODD customisation of ODD.
* '''Suggested solutions:''' I think the new @source attribute makes a major step in this direction
* '''Points for discussion:'''
** None so far

=== Problem: Referencing ODD from Document Instance ===
* '''Desc:''' The best place to reference an ODD in a document instance that creates the schema that the document instance is meant to validate against.  Equally, whether an ODD can be embedded (or XIncluded) into a document instance.  This would create a truly portable TEI document which held the document itself, and the means to create the schema and schema documentation all in a single document.  This is potentially useful as an archival format.
* '''Suggested solutions:''' 
*Doesn't Roma now include details of the ODD from which a schema was generated as a comment inside the schema? That is probably as far as we should go in this direction.
** But Lou, a mere link to a TEI source, whilst an improvement isn't a consistently machine-processable way of storing that information.  If I want to process a bunch of TEI document instances and find out what ODD they were created against, I have no good method of doing so.  Somewhere in the header (in encodingDesc? tagsDecl?) should be an appropriate place for someone to, at very least, store a &lt;ptr/&gt; to the ODD file.  XML comments inside generated schemas are not reliable and you may not have a copy of the schema, but want to regenerate it from the ODD.  The simple case of embedding a link in the teiHeader somewhere seems quite a trivial bug in that the TEI doesn't make any recommendation of where to put it (so a prose change and maybe allowing <ptr/> somewhere). Comments in XML can be and are thrown away by XML processors according to the spec.  The more difficult case of embedding the entire ODD with the document as an archival format is admittedly more extreme... I mean I have an example ODD which does this by allowing instances to embed it in encodingDesc, but a better solution might be more useable for archival formats of the TEI.


=== Problem: Classification of Elements as belonging to one or more category to aid interoperability ===
* '''Desc:''' This may be already possible in TEI ODD, but not clearly documented for this purpose. The idea is that any form of customization inside a &lt;schemaSpec&gt; or any element/attribute/class should be able to be categorized as to its nature(s). This categorization can then be used to know whether this item is considered important for interchange/interoperability on one or more lossy exports of the document for interchange or interoperable uses. Thus for various uses elements of a certain category could just be silently ignored, whereas others could be processed following their 'equiv', and other preserved as essential, etc.


[[Category:Customization|!]]