Third party conventions - Revision history

Piotr Banski: Undo revision 5164 by Piotr Banski (Talk)

2009-02-01T22:57:09Z

Undo revision 5164 by Piotr Banski (Talk)

Piotr Banski: recat

2009-02-01T22:52:39Z

recat

Piotr Banski: + category

2009-01-29T11:13:34Z

+ category

Brettz9: +see also section

2008-03-04T15:16:04Z

+see also section

Brettz9: +namespaced attribute values +@ns for procInst

2008-03-02T23:41:03Z

+namespaced attribute values +@ns for procInst

Brettz9: +internal link

2008-03-02T16:14:59Z

+internal link

Brettz9: started page

2008-03-02T16:09:49Z

started page

New page

Besides officially recommended practice, while there are no official means of indicating within a TEI document a particular schema, etc. used by a TEI document (besides a clue given by <TEI>'s @version), third party conventions might be used to suggest customizations for certain domains or purposes (e.g., for an already TEI conformant document, a customization might indicate the expansion of TEI suggested optional attribute values (or constrain them in cases where no suggested values already exist)).

I have started the page here for any who wish to list their conventions. Please realize that these should not be construed as being officially endorsed, since TEI has already decided not to endorse even any specific method of association of such conventions. They are simply presented here in the event others in the community might wish to coalesce around a particular (unofficial) convention.

==Association methods==

While there are no official means for indicating which schema a particular TEI document follows, exactly how it could or should be done for one convention (or even a community consensus on how it could be done for most conventions) might be discussed here.

XML provides the processing instruction ( <? ?> ) which might be used as the means of accomplishing this, given that it does not break conformance and can be safely ignored by TEI conformant processors, regardless of whether they enforce any further restrictions added by the convention. A logical place for the processing instruction might be at the top of the document after the XML Declaration, <?xml ?> , (which looks like a processing instruction but is not), though if an application needs a context-sensitive instruction, that can be added elsewhere in the document (besides within attributes, etc.).

Conventions listed here might wish to also indicate the specific processing instruction to use with their convention (e.g., <?physics-typology ?>). I'd like to propose <?tei-ext ... ?> for all such conventions, whereby pseudo-attributes within the processing instruction could indicate the name (@name) of the specific classification type or version (@version), point to a schema (@schema), etc. With the presence of this proposed (nonofficial) pseudo-convention, processors might attempt to detect whether a particular extension or its version were supported. Note that this use of the word "extension" does not imply that the document is not algorithmically conformant, as it could define a mere (conformant) subset of TEI (which could be used, for example, by an incomplete implementation of a TEI processor to determine whether it could support the document).

==Conventions==

* (List specific conventions here)

← Older revision		Revision as of 22:57, 1 February 2009
Line 1:		Line 1:
−	[[Category:~~Recommended Practice~~]]	+	[[Category:Third party conventions]]
	Besides officially [[TEI Recommended Practice\|recommended practice]], while there are no official means of indicating within a TEI document a particular schema, etc. used by a TEI document (besides a clue given by <TEI>'s @version), third party conventions might be used to suggest customizations for certain domains or purposes (e.g., for an already TEI conformant document, a customization might indicate the expansion of TEI suggested optional attribute values (or constrain them in cases where no suggested values already exist)).		Besides officially [[TEI Recommended Practice\|recommended practice]], while there are no official means of indicating within a TEI document a particular schema, etc. used by a TEI document (besides a clue given by <TEI>'s @version), third party conventions might be used to suggest customizations for certain domains or purposes (e.g., for an already TEI conformant document, a customization might indicate the expansion of TEI suggested optional attribute values (or constrain them in cases where no suggested values already exist)).

← Older revision		Revision as of 22:52, 1 February 2009
Line 1:		Line 1:
−	[[Category:~~Third party conventions~~]]	+	[[Category:Recommended Practice]]
	Besides officially [[TEI Recommended Practice\|recommended practice]], while there are no official means of indicating within a TEI document a particular schema, etc. used by a TEI document (besides a clue given by <TEI>'s @version), third party conventions might be used to suggest customizations for certain domains or purposes (e.g., for an already TEI conformant document, a customization might indicate the expansion of TEI suggested optional attribute values (or constrain them in cases where no suggested values already exist)).		Besides officially [[TEI Recommended Practice\|recommended practice]], while there are no official means of indicating within a TEI document a particular schema, etc. used by a TEI document (besides a clue given by <TEI>'s @version), third party conventions might be used to suggest customizations for certain domains or purposes (e.g., for an already TEI conformant document, a customization might indicate the expansion of TEI suggested optional attribute values (or constrain them in cases where no suggested values already exist)).

@@ Line 1: / Line 1: @@
 Besides officially [[TEI Recommended Practice|recommended practice]], while there are no official means of indicating within a TEI document a particular schema, etc. used by a TEI document (besides a clue given by <TEI>'s @version), third party conventions might be used to suggest customizations for certain domains or purposes (e.g., for an already TEI conformant document, a customization might indicate the expansion of TEI suggested optional attribute values (or constrain them in cases where no suggested values already exist)).
-I have started the page here for any who wish to list their conventions. Please realize that these should not be construed as being officially endorsed, since TEI has already decided not to endorse even any specific method of association of such conventions. They are simply presented here in the event others in the community might wish to coalesce around a particular (unofficial) convention.
+I have started the page here for any who wish to list their conventions. Please realize that these should not be construed as being officially endorsed, since TEI has already decided not to endorse even any specific method of association of such conventions. They are simply presented here in the event others in the community might wish to coalesce around a particular (unofficial) convention. Please place the line <nowiki>[[Category:Third party conventions]]</nowiki> at the beginning or the end of your article, in order to [[:Category:Third party conventions|categorise it properly]].
 ==Association methods==

← Older revision		Revision as of 15:16, 4 March 2008
Line 48:		Line 48:

	* (List specific conventions here)		* (List specific conventions here)
		+
		+	==See also==
		+	* [[Stylesheets]] (for third party conventions for formatting)
		+	* [[:Category:Customization\|Customization]] (for schema customizations)

← Older revision		Revision as of 16:14, 2 March 2008
Line 1:		Line 1:
−	Besides officially recommended practice, while there are no official means of indicating within a TEI document a particular schema, etc. used by a TEI document (besides a clue given by <TEI>'s @version), third party conventions might be used to suggest customizations for certain domains or purposes (e.g., for an already TEI conformant document, a customization might indicate the expansion of TEI suggested optional attribute values (or constrain them in cases where no suggested values already exist)).	+	Besides officially [[TEI Recommended Practice\|recommended practice]], while there are no official means of indicating within a TEI document a particular schema, etc. used by a TEI document (besides a clue given by <TEI>'s @version), third party conventions might be used to suggest customizations for certain domains or purposes (e.g., for an already TEI conformant document, a customization might indicate the expansion of TEI suggested optional attribute values (or constrain them in cases where no suggested values already exist)).

	I have started the page here for any who wish to list their conventions. Please realize that these should not be construed as being officially endorsed, since TEI has already decided not to endorse even any specific method of association of such conventions. They are simply presented here in the event others in the community might wish to coalesce around a particular (unofficial) convention.		I have started the page here for any who wish to list their conventions. Please realize that these should not be construed as being officially endorsed, since TEI has already decided not to endorse even any specific method of association of such conventions. They are simply presented here in the event others in the community might wish to coalesce around a particular (unofficial) convention.

@@ Line 7: / Line 7: @@
 While there are no official means for indicating which schema a particular TEI document follows, exactly how it could or should be done for one convention (or even a community consensus on how it could be done for most conventions) might be discussed here.
 XML provides the processing instruction ( <? ?> ) which  might be used as the means of accomplishing this, given that it does not break conformance and can be safely ignored by TEI conformant processors, regardless of whether they enforce any further restrictions added by the convention. A logical place for the processing instruction might be at the top of the document after the XML Declaration, <?xml ?> , (which looks like a processing instruction but is not), though if an application needs a context-sensitive instruction, that can be added elsewhere in the document (besides within attributes, etc.).
-Conventions listed here might wish to also indicate the specific processing instruction to use with their convention (e.g., <?physics-typology  ?>). I'd like to propose <?tei-ext ... ?> for all such conventions, whereby pseudo-attributes within the processing instruction could indicate the name (@name) of the specific classification type or version (@version), point to a schema (@schema), etc. With the presence of this proposed (nonofficial) pseudo-convention, processors might attempt to detect whether a particular extension or its version were supported. Note that this use of the word "extension" does not imply that the document is not algorithmically conformant, as it could define a mere (conformant) subset of TEI (which could be used, for example, by an incomplete implementation of a TEI processor to determine whether it could support the document).
+Conventions listed here might wish to also indicate the specific processing instruction to use with their convention (e.g., <?physics-typology  ?>). I'd like to propose <?tei-ext ... ?> for all such conventions, whereby pseudo-attributes within the processing instruction could indicate the name (@name) of the specific classification type or version (@version), point to a schema (@schema), or point to a namespace (@ns), etc. With the presence of this proposed (nonofficial) pseudo-convention, processors might attempt to detect whether a particular extension or its version were supported. Note that this use of the word "extension" does not imply that the document is not algorithmically conformant, as it could define a mere (conformant) subset of TEI (which could be used, for example, by an incomplete implementation of a TEI processor to determine whether it could support the document).
 ==Conventions==
 * (List specific conventions here)