Conformance - Revision history

Piotr Banski: nothing links here; looks like a candidate for deletion to me

2009-01-29T11:49:03Z

nothing links here; looks like a candidate for deletion to me

James at 22:32, 21 October 2007

2007-10-21T22:32:03Z

Piotr Banski: removing TEI:P4, as this seems to be P5 stuff; it needs a rewrite to become a doc

2007-09-25T20:54:41Z

removing TEI:P4, as this seems to be P5 stuff; it needs a rewrite to become a doc

Piotr Banski: + categories

2007-09-25T12:07:48Z

+ categories

Lou at 09:48, 25 October 2006

2006-10-25T09:48:46Z

Rahtz: /* TEI conformance */

2006-08-24T22:39:34Z

‎TEI conformance

Rahtz at 22:33, 24 August 2006

2006-08-24T22:33:52Z

Syd at 22:05, 24 August 2006

2006-08-24T22:05:41Z

Rahtz at 11:57, 23 August 2006

2006-08-23T11:57:04Z

Rahtz at 13:42, 22 August 2006

2006-08-22T13:42:41Z

← Older revision		Revision as of 11:49, 29 January 2009
Line 1:		Line 1:
		+	[[category:scratchpad]]
	==TEI conformance ideas==		==TEI conformance ideas==

← Older revision		Revision as of 22:32, 21 October 2007
Line 5:		Line 5:
	chapter, for the TEI Technical Council to debate. ]		chapter, for the TEI Technical Council to debate. ]

−	TEI-Conformant documents can be of any one of five different '''degrees''' of interchangability. These are as follow. There is a universal exception for any modification, that the TEI namespace may not be omitted or changed,
−	~~and the <TEI>, <teiHeader>, and <text> elements may not be removed.~~

−	# The document conforms to the tei_all schema, or any valid subset of that (ie with fewer elements, tighter datatyping etc); with the exception that the TEI namespace may not be omitted or changed, the <TEI> element may not be removed, and the <teiHeader> element may not be removed.	+	'''THE REST OF THIS PAGE HAS BEEN DELETED SINCE THESE ISSUES HAVE SINCE BEEN DEBATED ON THE COUNCIL LIST AND RESULTED IN THE REWRITTEN CHAPTER NOW PART OF TEI P5.'''
−	~~## The definition of elements may be suppressed, so deleting the associated elements from the modified schema.~~
−	## The name (generic identifier) associated with an element may be changed, while preserving the semantics of the element. Note, however, that the new name may not clash with the default name of any element defined in these Guidelines.
−	~~## An <equiv> element in the ODD should be used to specify the TEI name for such renamed elements.~~
−	~~## Those parts of the content model of an element which are specified by classes may be extended by adding members to the classes.~~
−	## Further attributes, together with their names and types, may be specified for an individual element and existing attributes for an individual element may be renamed. Note that the new names may not clash with names of existing attributes for the element.
−	~~## Further attributes, together with their names and types, may be specified for the elements in a particular class and those inheriting characteristics from that class.~~
−	~~## Any derivation from the tei_all schema must be expressed in an accompanying ODD specification~~
−	~~# The document conforms to a schema which adds new elements to the TEI but provides an ODD specification which uses the <equiv> mechanism which explains how to map these to unchanged TEI~~
−	# The document conforms to a schema which extends the TEI element set by manipulation of the TEI class system, or extends the content model model of TEI elements to allow elements from other namespaces
−	~~# The document conforms to a schema which is based on the TEI but has changed the content model for elements so that normal TEI documents would no longer conform~~
−	~~# The document uses the TEI elements in the TEI namespace, but embeds them within another schema~~
−
−	~~Documents which use TEI names for elements but do not use the TEI namespace are regarded only as~~ '''TEI~~-like'''.~~
−
−	~~In addition to the conformance type, a document may claim AACR~~
−	~~compatibility if the elements <TEI> or <teiCorpus>, <teiHeader> and~~
−	~~the child elements <title>, <sourceStmt> and <publicationStmt> in the~~
−	~~header are retained with those names in the schema.~~
−
−	~~--------comments from Laurent 30 sep 06 (added by Lou)~~
−	~~-----------~~
−
−	~~I know I should work on the wiki, but I'd rather not postpone writing down my comments and a short trip by train between Göttingen and Berlin looks like the perfect place to do so...~~
−
−	I basically think that we should not impose a conformance grid (or levels - I know Seb's intentions were not to mean levels as an evaluation criterion), but a guide for people using the TEI to position themselves. I would thus suggest to take the conformance ideas as we have them in the current docuement and present them officially as a "conformance guide". Doing so I would suggest to reorganise the content under three heading, that would correspond to the "three ways to be conformant to the TEI". The consequence would be that when someone claims to be conformant to the TEI, he should be able to say along under which heading(s - there can be more then one) he situates himself.
−
−	~~The three heading would be the following one:~~
−
−	~~TEI subset~~
−	~~which would cover item 1 (general principle) and subitems 1.1, 1.2, 1.3~~
−
−	~~TEI extension~~
−	~~covering 1.4, 1.5, 1.6, 2, 3, which I would subdivide on TEI supported extensions (SVG?) vs. proprietary extensions~~
−
−	~~TEI based specifications (a missing item in the document)~~
−	~~any specification based on ODD that may or may not reuse existing TEI objects~~
−
−
−	~~Notes:~~
−	~~item 4 - I am not sure I would really mention that as a possible TEI conformant option.~~
−
−	~~item 5 - I would introduce the notion of "local conformance" since the two categories of subset- and extension- conformance could apply there.~~
−
−	~~I would impose preserving the TEI namespace for all elements taken from the TEI guidelines~~
−
−	~~Comments?~~
−	~~Laurent~~
−
−	~~------------- further comments from Martin on 2 oct (added by Lou)~~
−
−	~~Hi there,~~
−
−	~~On this bit:~~
−
−	~~>> TEI extension~~
−	~~>> covering 1.4, 1.5, 1.6, 2, 3, which I would subdivide on TEI supported~~
−	~~>> extensions (SVG?) vs. proprietary extensions~~
−
−	~~I think we need to know what is meant by "supported". One option is to~~
−	~~say that an external specification such as SVG is "supported" if the~~
−	~~Council has formally agreed that it is a worthwhile and workable~~
−	~~extension to TEI, AND that a standard method has been specified for~~
−	~~integrating it. For instance, this is what I would hope happens with~~
−	~~regard to SVG:~~
−
−	~~-SVG 1.1 is selected as the most appropriate SVG version to extend~~ P5.
−
−	~~-A sample ODD file is provided which Roma can handle, and which causes~~
−	~~the <svg> element from the SVG namespace to be an allowed child of TEI~~
−	~~<figure>.~~
−
−	~~-The Roma interface itself also allows the selection and inclusion of~~
−	~~SVG in the same way, so anyone not comfortable editing ODD files.~~
−
−	~~Any project using SVG in this way would be deemed "conformant" at the~~
−	~~TEI supported extension level. Anyone would of course be free to~~
−	~~integrate SVG in another fashion, such as allowing <svg> anywhere, but~~
−	~~that would not be conformant at the supported extension level.~~
−
−	~~Is this how everyone else is imagining supporting external standards?~~
−
−	~~Cheers,~~
−	~~Martin~~
−
−	~~------------~~
−
−	~~[Discussion then veered off to question of adding SVG support via Roma]~~
−
−	~~Le 2 oct. 06 à 18:33, Martin Holmes a écrit :~~
−
−	~~> > Hi Sebastian,~~
−	~~> >~~
−	~~> > Sebastian Rahtz wrote:~~
−	~~>> >> I think your description is fairly spot-on, Martin. Of course, people~~
−	~~>> >> can write a customization to include eg Docbook, but we kind~~
−	~~>> >> of think that's silly; but we don~~'~~t think it's at all silly~~
−	~~>> >> to include SVG, so we show them how. That seems fair~~
−	~~>> >> distinction to me.~~
−	~~>> >> I can add a "include SVG in content of <figure>?" tick box~~
−	~~>> >> in Roma; where would you like to see it?~~
−	~~> >~~
−	~~> > That would be wonderful. I~~'~~m not sure where would be the best place~~
−	~~> > for~~
−	~~> > it; since we~~'~~re anticipating that there might be support for many~~
−	~~> > external schemas, perhaps there should be another tab after "Modules"~~
−	~~> > labelled "Extensions" or something, where SVG and other extensions~~
−	~~> > could be added.~~
−
−	~~For sake of simplicity, I would suggest that layers of customizations~~
−	~~are kept at the same place in Roma. Having experimenting introducing~~
−	~~people to the environment I feel more and more the need for~~
−	~~legibility in the various features we offer with TEI+ODD.~~
−
−	~~[[Category: Customization\|Conformance]]~~
−	~~[[Category: TEI:P5\|Conformance]]~~

← Older revision		Revision as of 20:54, 25 September 2007
Line 123:		Line 123:

	[[Category: Customization\|Conformance]]		[[Category: Customization\|Conformance]]
−	~~[[Category: TEI:P4\|Conformance]]~~
	[[Category: TEI:P5\|Conformance]]		[[Category: TEI:P5\|Conformance]]

@@ Line 120: / Line 120: @@
 are kept at the same place in Roma. Having experimenting introducing
 people to the environment I feel more and more the need for
-legebility in the various features we offer with TEI+ODD.
+legibility in the various features we offer with TEI+ODD.

@@ Line 5: / Line 5: @@
 chapter, for the TEI Technical Council to debate. ]
-TEI-Conformant documents can be of any one of five different '''degrees''' of interchangability. These are as follow. There is a universal exception for any modification, that the TEI namespace may not be omitted or changed,
+TEI-Conformant documents can be of any one of five different '''degrees''' of interchangability. These are as follow. There is a universal exception for any  modification, that the TEI namespace may not be omitted or changed,
 and the <TEI>, <teiHeader>, and <text> elements may not be removed.
@@ Line 27: / Line 27: @@
 the child elements <title>, <sourceStmt> and <publicationStmt> in the
 header are retained with those names in the schema.

@@ Line 1: / Line 1: @@
-==TEI conformance==
+==TEI conformance ideas==
-[ NOTE: This page is purely for discussion purposes.
+[ NOTE: This page is '''NOT''' the current or proposed policy of the TEI Consortium!!!!
-It does not reflect the policy of the TEI Consortium]
+It contains some strawman proposals for the TEI Guidelines conformance
 TEI-Conformant documents can be of any one of five different '''degrees''' of interchangability. These are as follow. There is a universal exception for any modification, that the TEI namespace may not be omitted or changed,

@@ Line 4: / Line 4: @@
 It does not reflect the policy of the TEI Consortium]
-TEI-Conformant documents can be of any one of five different '''degrees''' of interchangability. These are as follow. Thetre is a universal exception for any modification,
+TEI-Conformant documents can be of any one of five different '''degrees''' of interchangability. These are as follow. There is a universal exception for any modification, that the TEI namespace may not be omitted or changed,
-that the TEI namespace may not be omitted or changed, the <TEI>, <teiHeader>, and <text> elements may not be removed,
+and the <TEI>, <teiHeader>, and <text> elements may not be removed.
 # The document conforms to the tei_all schema, or any valid subset of  that (ie with fewer elements, tighter datatyping etc); with the exception that the TEI namespace may not be omitted or changed, the <TEI> element may not be removed, and the <teiHeader> element may not be removed.

@@ Line 4: / Line 4: @@
 It does not reflect the policy of the TEI Consortium]
-A document may claim TEI conformance according to 5 types. Each
+TEI-Conformant documents can be of any one of five different '''degrees''' of interchangability. These are as follow. Thetre is a universal exception for any modification,
-document should contain a link in its metadata pointing to a
+that the TEI namespace may not be omitted or changed, the <TEI>, <teiHeader>, and <text> elements may not be removed,
-'''TEI Conformance Statement''' (TCS) which must provide the following
+and there must be a title statement, a source description, and a publication statement within the <teiHeader>.
 # The document conforms to the tei_all schema, or any valid subset of  that (ie with fewer elements, tighter datatyping etc); with the exception that the TEI namespace may not be omitted or changed, the <TEI> element may not be removed, and the <teiHeader> element may not be removed.
@@ Line 31: / Line 18: @@
 # The document conforms to a schema which adds new elements to the TEI but provides an ODD specification which uses the <equiv> mechanism which explains how to map these to unchanged TEI
 # The document conforms to a schema which extends the   TEI element set by manipulation of the TEI class system, or extends the content model model of TEI elements to allow elements from other namespaces
 # The document conforms to a schema which is based on the TEI  but has changed the content model for elements so that normal TEI  documents would no longer conform
 # The document uses the TEI elements in the TEI namespace, but embeds them within  another schema
@@ Line 42: / Line 26: @@
 compatibility if the elements <TEI> or <teiCorpus>, <teiHeader> and
 the child elements <title>, <sourceStmt> and <publicationStmt> in the
-header are retained in the schema.
+header are retained with those names in the schema.

← Older revision		Revision as of 13:42, 22 August 2006
Line 1:		Line 1:
	==TEI conformance==		==TEI conformance==
		+
		+	[ NOTE: This page is purely for discussion purposes.
		+	It does not reflect the policy of the TEI Consortium]

	A document may claim TEI conformance according to 5 levels. Each		A document may claim TEI conformance according to 5 levels. Each