|
|
| (One intermediate revision by one other user not shown) |
| Line 1: |
Line 1: |
| | + | [[category:scratchpad]] |
| | ==TEI conformance ideas== | | ==TEI conformance ideas== |
| | | | |
| Line 5: |
Line 6: |
| | 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]]
| |
