Difference between revisions of "ODD-dev"
Jump to navigation
Jump to search
LouBurnard (talk | contribs) (→Problem: Chaining of ODDs) |
LouBurnard (talk | contribs) (→Problem: Referencing ODD from Document Instance) |
||
| Line 46: | Line 46: | ||
=== Problem: Referencing ODD from Document Instance === | === 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. | * '''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:''' | + | * '''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. | |
** None so far | ** None so far | ||
Revision as of 23:31, 9 November 2010
This page has been set up to record underlying problems with the TEI ODD language and look at methods for improving them.
Contents
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 <tei:head> element but have it be a member of att.mySpecialAttributes to give it some extra attributes, but only when it is inside <figure>”. This may also relate to Per-element attribute-based customisation in specific circumstances mentioned below.
- Suggested solutions: none so far
- Points for discussion:
- I (Syd) am under the impression that the problem cannot occur exactly as described. If you add attributes to the <head> element (whether directly or by adding it to the class att.mySpecialAttributes), it will not validate against tei_all, and has to be placed in another namespace. I.e., it cannot be <tei:head>.
- Reply: Perhaps poorly phrased in the description. How about we reverse it: let's say you want to remove @n from <figure> globally, but then allow it back when inside <figure>. Obviously you can test that with schematron, but not (I think) simply by adding <figure> to a new attribute class. James 10:23, 1 September 2009 (EDT)
- That said, the desire to have special attributes on <my:head> when it is a child of <figure> 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 <my:head> in the ODD tagdoc, and then add a “don't use these attributes unless a child of <figure>” as a <constraintSpec>, 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.
- None so far
