[tei-council] namespaces and customization

[Kevin Hawkins]

Like James, I read the intention of P5 that way: that you're supposed to 
use a namespace for anything that's not a pure subset.  But it's not 
entirely clear to me that this was really the intention -- see my 
original message in this thread.  I questioned this reading because I 
share Martin's questioning that every simple modification -- say, of 
adding a @type to an element -- requires moving it out of the TEI namespace.

At the least I would like to see the intention clarified in P5, and at 
the most I would like us to revisit the intention.  I'm not sure the 
intention is wrong, but I'm not sure it's right either.  If we are 
revisiting the intention, it would be worth talking to Bryan 
Pytlik-Zillig and/or others who have done work on normalizing documents. 
  I wonder whether they would find use of a new namespace useful or a 
hassle.

On 12/19/11 4:05 AM, Laurent Romary wrote:
> Still, I understand Martin's worry and if we think formally of cleanness as subsumption (along a relation is-more constrained-than) than adding eg to att.typed could be seen as clean (any processor with a TEI-all coverage would not have a problem with this, it would just not "see" the corresponding attributes). I let the future council chair to lead this discussion next year :-}
> Laurent
>
> Le 19 déc. 2011 à 09:58, James Cummings a écrit :
>
>> On 19/12/11 03:28, Martin Holmes wrote:
>>> That's a very good question. Personally, I wouldn't have thought that
>>> customizing an existing element would require moving it to a new
>>> namespace -- unless you changed it beyond all recognition, but in that
>>> case I would have thought giving it a new name would make more sense.
>>> Surely just adding tei:eg to att,typed wouldn't require moving it out of
>>> the tei: namespace?
>>
>> I think that is exactly the intention. If you add something to an
>> element making it not a pure subset of the original element (conformant)
>> or automatically able to be cleanly reversed (conformable) then it is no
>> longer the TEI element as the TEI has defined it. Thus should be in a
>> new namespace. You don't want to have something that purports to be a
>> TEI 'eg' element but has lots of attributes which it doesn't have in the
>> TEI, unless these attributes are in a non-TEI namespace. So you could
>> add @my:type and @my:subtype to 'eg' and be perfectly TEI conformant,
>> but adding att.typed to 'eg' is an unclean change and thus should be
>> signalled by a namespace.
>>
>> I believe that was the thinking at least,
>>
>> -James
>>
>>
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 11-12-18 03:28 PM, Kevin Hawkins wrote:
>>>>       From reading chapter 23 of the Guidelines, I'm unclear on whether you
>>>> are supposed to define a new namespace for every element or attribute
>>>> affected by an unclean customization.  I don't see it explicitly stated,
>>>> but it sounds that way.  For example, in section 23.2.1.5,<tei:eg>    is
>>>> modified to add it to att.typed, but as I understand it, the element
>>>> then moves into a new namespace (http://example.com/ns).  So each
>>>> instance of<eg>    should actually be<myNamepsace:eg>    instead of
>>>> <tei:eg>.  Is that right?
>>>>
>>>> Furthermore, I see this sentence in section 23.2.2, after a discussion
>>>> of definining a namespace:
>>>>
>>>> "Similar methods may be used if a modification (clean or unclean) is
>>>> made to the content model or some other aspect of an element, or if it
>>>> declares a new element."
>>>>
>>>> In what cases would you define a new namespace for a clean customization
>>>> of an element?
>>>>
>>>> --Kevin
>>
>>
>> --
>> Dr James Cummings, InfoDev,
>> Computing Services, University of Oxford
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>
> Laurent Romary
> INRIA&  HUB-IDSL
> laurent.romary at inria.fr
>
>
>