[tei-council] conformance draft

[Arianna Ciula]

 > 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.

Totally agree with James on this and with Conan on the rest.

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