ODD-dev - Revision history

Lou: /* Problems which do not seem amenable to ODD as it stands and need a new version */

2017-10-02T19:29:08Z

Problems which do not seem amenable to ODD as it stands and need a new version

← Older revision		Revision as of 19:29, 2 October 2017
Line 26:		Line 26:

	=== Problems which do not seem amenable to ODD as it stands and need a new version ===		=== Problems which do not seem amenable to ODD as it stands and need a new version ===
	* Durand Conundrum: Express content models as native TEI?		* Durand Conundrum: Express content models as native TEI? : DONE
	* Subclasses (element <foo> has a simpler content model if its in the header)		* Subclasses (element <foo> has a simpler content model if its in the header)
	* Attribute/content interdependency (if <foo>, then attribute @y must be used)		* Attribute/content interdependency (if <foo>, then attribute @y must be used)
Line 32:		Line 32:
	* Expressing XPath-based constraints (Schematron) in a TEI language with embedded documentation		* Expressing XPath-based constraints (Schematron) in a TEI language with embedded documentation
	* Short-cut content models based entirely on model classes (<classes><containerOf key="model.foo"/></classes>)		* Short-cut content models based entirely on model classes (<classes><containerOf key="model.foo"/></classes>)


	==Other problems / earlier discussions ==		==Other problems / earlier discussions ==

Piotr Banski: back to default sorting within "Customizations"

2016-12-29T14:13:46Z

back to default sorting within "Customizations"

← Older revision		Revision as of 14:13, 29 December 2016
Line 1:		Line 1:
	[[Category:Suggestions]]		[[Category:Suggestions]]
			[[Category:Customization]]

	This page has been set up to record underlying problems with the TEI [[ODD]] language and look at methods for improving them.		This page has been set up to record underlying problems with the TEI [[ODD]] language and look at methods for improving them.
Line 83:		Line 84:
	=== Problem: Classification of Elements as belonging to one or more category to aid interoperability ===		=== 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 <schemaSpec> 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.		* '''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 <schemaSpec> 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\|!]]~~

James at 12:01, 15 July 2012

2012-07-15T12:01:01Z

James at 12:01, 13 July 2012

2012-07-13T12:01:21Z

@@ Line 3: / Line 3: @@
 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.

Rahtz: /* Problem: Per-element attribute-based customisation */

2012-07-11T21:04:03Z

Problem: Per-element attribute-based customisation

← Older revision		Revision as of 21:04, 11 July 2012
Line 26:		Line 26:
	=== Problem: Per-element attribute-based customisation ===		=== 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.		* '''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~~		* '''Suggested solutions:''' This is probably the request of http://purl.org/tei/fr/337683, allowing specialization of elements back at source level rather than in a customization
	* '''Points for discussion:'''		* '''Points for discussion:'''
	** None so far		** None so far



	=== Problem: attribute/content interdependency ===		=== Problem: attribute/content interdependency ===

Mholmes: /* Problem: Referencing ODD from Document Instance */

2012-04-17T21:01:15Z

Problem: Referencing ODD from Document Instance

← Older revision		Revision as of 21:01, 17 April 2012
Line 47:		Line 47:

	=== Problem: Referencing ODD from Document Instance ===		=== Problem: Referencing ODD from Document Instance ===
			NOTE: This was discussed by Counci in Ann Arbor in April 2012, and will be going ahead. The ticket for this is [[http://purl.org/tei/fr/1650195]].
	* '''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.		*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 <ptr/> 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.		** 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 <ptr/> 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 ===		=== Problem: Classification of Elements as belonging to one or more category to aid interoperability ===

Kshawkin: added Category:Suggestions

2012-04-17T20:53:17Z

added Category:Suggestions

← Older revision		Revision as of 20:53, 17 April 2012
Line 1:		Line 1:
			[[Category:Suggestions]]

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

James at 10:45, 14 March 2012

2012-03-14T10:45:11Z

← Older revision		Revision as of 10:45, 14 March 2012
Line 48:		Line 48:
	* '''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.		*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 <ptr/> 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.		** 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 <ptr/> 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 <schemaSpec> 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\|!]]		[[Category:Customization\|!]]

James: /* Problem: Referencing ODD from Document Instance */

2010-11-09T21:48:29Z

Problem: Referencing ODD from Document Instance

← Older revision		Revision as of 21:48, 9 November 2010
Line 47:		Line 47:
	* '''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.		*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~~		** 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 <ptr/> 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.



	[[Category:Customization\|!]]		[[Category:Customization\|!]]

LouBurnard: /* Problem: Referencing ODD from Document Instance */

2010-11-09T21:31:09Z

Problem: Referencing ODD from Document Instance

← Older revision		Revision as of 21:31, 9 November 2010
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:''' ~~none so far~~		* '''Suggested solutions:'''
	* '''Points for discussion:'''		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

← Older revision		Revision as of 12:01, 15 July 2012
Line 4:		Line 4:

	== Areas of concern for [[ODD-Dev-meetingDH2012]] ==		== Areas of concern for [[ODD-Dev-meetingDH2012]] ==

			The following areas of concern were collated by Sebastian Rahtz for discussion at the DH2012 ODD meeting:

	=== Areas of ODD2 which are not expressive enough but which can be fixed without a new paradigm===		=== Areas of ODD2 which are not expressive enough but which can be fixed without a new paradigm===
			* Module inter-dependency (if you ask for module X, also bring in module Y)
	* Module inter-dependency (if you ask for module X, also bring in module Y)		* Bertrand's model classes questions
	* Bertrand's model classes questions

	=== Areas of ODD2 which are not well-enough defined ===		=== Areas of ODD2 which are not well-enough defined ===
	* the processing model. what order are things worked on?		* the processing model. what order are things worked on?
	* there is no defined test suite for an ODD processor		* there is no defined test suite for an ODD processor
	* is the DTD/RELAXNG/XSD output defined or can a processor choose different methods?		* is the DTD/RELAXNG/XSD output defined or can a processor choose different methods?
	* what documentation generation options are supported? how to document customizations		* what documentation generation options are supported? how to document customizations

	=== ODD-processing which is unimplemented at present ===		=== ODD-processing which is unimplemented at present ===
	* Chaining of ODDs (a customization of a customization)		* Chaining of ODDs (a customization of a customization)
	* Per-element attribute-based customisation at source (specialized @type on div)		* Per-element attribute-based customisation at source (specialized @type on div)
	* Supporting multiple customizations of the same element (in different areas)		* Supporting multiple customizations of the same element (in different areas)
	* Declaring an attribute class and then customizing it straightaway		* Declaring an attribute class and then customizing it straightaway
	* Generating XSD natively		* Generating XSD natively

	=== Problems which do not seem amenable to ODD as it stands and need a new version ===		=== Problems which do not seem amenable to ODD as it stands and need a new version ===
	* Durand Conundrum: Express content models as native TEI?		* Durand Conundrum: Express content models as native TEI?
	* Subclasses (element <foo> has a simpler content model if its in the header)		* Subclasses (element <foo> has a simpler content model if its in the header)
	* Attribute/content interdependency (if <foo>, then attribute @y must be used)		* Attribute/content interdependency (if <foo>, then attribute @y must be used)
	* Alternation of attribute/element (either child <y> or attribute @y)		* Alternation of attribute/element (either child <y> or attribute @y)
	* Expressing XPath-based constraints (Schematron) in a TEI language with embedded documentation		* Expressing XPath-based constraints (Schematron) in a TEI language with embedded documentation
	* Short-cut content models based entirely on model classes (<classes><containerOf key="model.foo"/></classes>)		* Short-cut content models based entirely on model classes (<classes><containerOf key="model.foo"/></classes>)