Difference between revisions of "ODD-dev"
Jump to navigation
Jump to search
m |
(→Problem: Subclasses: add some discussion) |
||
| Line 10: | Line 10: | ||
=== Problem: Subclasses === | === 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. | + | * '''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><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><figure></tt>”. This may also relate to Per-element attribute-based customisation in specific circumstances mentioned below. |
* '''Suggested solutions:''' none so far | * '''Suggested solutions:''' none so far | ||
* '''Points for discussion:''' | * '''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><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><tei:head></tt>. |
| − | + | *# That said, the desire to have special attributes on <tt><my:head></tt> when it is a child of <tt><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><my:head></tt> in the ODD tagdoc, and then add a “don't use these attributes unless a child of <tt><figure></tt>” as a <tt><constraintSpec></tt>, i.e., in Schematron. | ||
=== Problem: Per-element attribute-based customisation === | === Problem: Per-element attribute-based customisation === | ||
Revision as of 15:46, 1 September 2009
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: none so far
- 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>.
- 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.
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: none so far
- 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: none so far
- Points for discussion:
- None so far
