[tei-council] conformance draft

Fri Mar 23 06:29:52 EST 2007

On 3/23/07, Arianna Ciula <arianna.ciula at kcl.ac.uk> wrote:
> Totally agree with James on this and with Conan on the rest.
>
TEI barbarians!

> Arianna
>
> James Cummings wrote:
> > Syd Bauman wrote:
> >> I am going to
> >> skip the nit-picks for now, mostly because all of Council need not be
> >> bothered.
> >
> > Do feel free to pass on the nit-picks privately.  That which doesn't
> > kill us...
> >
> >> One: ODD validate against which schema?
> >> ---- --- -------- ------- ----- -------
> >> At several points the chapter refers to the need for a "valid TEI
> >> ODD" file. This is well and good, but valid against what?
> >
> > Make sense, agreed that this should be more specific.
> >
> >> Two: Exemplars
> >> ---- ---------
> >> I feel that too much weight is placed on the TEI Customization
> >> Exemplars, although I don't have specific suggestions for improvement
> >> at the moment.
> >
> > My suggestion is that the discussion here should lessened, but that they
> > be discussed in more depth in the chapter on customisation/modification.
> >
> >>
> >> Three: Schemas
> >> ------ -------
> >> I think it is important to make it clearer that validation against a
> >> schema is a necessary, but insufficient, condition of conformance --
> >> that there are constraints required by the Guidelines that are not
> >> schema-enforced. (E.g., that a hand= attribute point to a <hand>
> >> element, not an <emph> inside a <salute>.)
> >
> > Yes, that should be stated more clearly.
> >
> >
> >> Furthermore, I think it is important to explain that DTD validation
> >> will not inform a user about as many constraints as will Relax NG
> >> validation.
> >
> > While DTD validation may not provide as many constraints, if the
> > document instance validates against a DTD generated from a TEI ODD is
> > the document instance somehow less conformant than if it is validated
> > against a Relax NG schema generated from the same ODD?  Either DTDs are
> > acceptable to validate TEI Conformant documents against or they are
> > not.  I admit that I have a little niggle worrying in the back of my
> > head about someone creating an ODD for a schema which would be
> > considered in one of those categories of TEI Conformance, but that the
> > lack of constraints in DTD means that document instances which validate
> > against the DTD are non-conformant because they don't include certain
> > constraints in the Relax NG version generated from the same ODD.  (Can
> > someone invent an occasion where this might happen that simultaneously
> > breaks conformance?) Maybe we should think about that more.
> >
> >>
> >> Four: namespace of new elements
> >> ----- --------- -- --- --------
> >> I am not at all sure it is a good idea that TEI require that new
> >> elements be in a separate namespace. I think that doing so
> >> * creates a higher barrier to actual use of the customization
> >>   mechanism
> >> * makes instances harder to read by humans
> >> * sends the wrong message politically -- that if you create a new
> >>   element, somehow you're not a member of the same TEI club
> >> for an extremely limited technical gain.
> >
> > I think I'm still going to try and take the moral high ground...I
> > recognise that it creates a barrier to use of the customisation
> > mechanism.  I'm not entirely convinced that it truly impairs human
> > readability.  Having a few namespace prefixes might actually clarify
> > things more.  I'm entirely used to xml:id now as an attribute.  I don't
> > think it sends the wrong message politically either...or at least you
> > can view that in two ways.  When you create a new element you get the
> > privilege of putting it in your own project's namespace, and the
> > comforting knowledge that the TEI namespace is kept pure.  When you use
> > other TEI documents you know the elements and their semantics because
> > they are in the TEI namespace.    I will admit that I am torn...I
> > understand how much of a pain it is to do things in multiple namespaces
> > even just in writing XSLT stylesheets, never mind full-blown
> > applications.  As an elected member of the council I feel I'm here to
> > support the interests of the members.  However, I'm torn between doing
> > what I feel is right and doing what is easier.  Would the membership
> > want me to make life easy on them, or really make use of namespaces in
> > the way I feel we should?
> >
> > The only real objection anyone has made so far concerning the
> > use-your-own-namespace-for-new-elements idea is that it is difficult.
> > Does anyone have any other arguments against this idea?
> >
> > While I unquestioningly accept that the use of namespaces in this way
> > means that it will be more difficult to use the customisation mechanism,
> > it might not pose an insurmountable difficulty or dissuade people from
> > customisation as much as we might expect.  Partly that depends on
> > front-end applications like webRoma.  If when I add a new element it is
> > also prompting me for the namespace (perhaps with a previously-used
> > suggestion) or something, then the barrier to use is lessened.  Couple
> > that with some XSLT examples handling multiple namespaces and a lot of
> > the fear is reduced.
> >
> >> Rather than make this a
> >> condition of conformance, I would like to see the definitions of the
> >> various categories of TEI-Conformant schemas (& documents)
> >> differentiate based on use of namespaces.
> >>
> >> So, e.g., rename "Extension Schema" to "Pure Extension Schema", and
> >> create a new category "Extension Schema", which permits the addition
> >> of new elements in the TEI namespace.
> >
> > This is certainly a possibility. Would the lack of namespace only occur
> > in this category of schema?  And even if the current conformance draft
> > was the final chapter, this is something I think many people would
> > probably do.  If we persist with this use of namespaces I think there
> > will be an increase in local encoding formats with transformations to
> > multi-namespaced TEI Conformant documents only for
> > interchange/deposit-with-archives/pleasing-the-funders, and such.  But
> > if using multiple namespaces is still the 'right' thing to do...then
> > should this dissuade us?
> >
> > No one has said anything about the section 1.7 'TEI Conformance and
> > Funding Bodies', since the claim of TEI Conformance is something that is
> > often added to funding applications (since I read scores of them for the
> > AHRC) in hopes of people saying "look how good we are, please, please
> > fund us", I thought that we should say something about Conformance in no
> > way indicating quality.  However, I wasn't quite sure how far we should
> > go along that road or other appropriate messages, etc.
> >
> > -James
> >
>
> --
> Dr Arianna Ciula
> Research Associate
> Centre for Computing in the Humanities
> King's College London
> Strand
> London WC2R 2LS (UK)
> Tel: +44 (0)20 78481945
> http://www.kcl.ac.uk/cch
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>


-- 
***************************************
Dot Porter, University of Kentucky
#####
Program Coordinator
Collaboratory for Research in Computing for Humanities
dporter at uky.edu          859-257-9549
#####
Editorial Assistant, REVEAL Project
Center for Visualization and Virtual Environments
porter at vis.uky.edu
***************************************