[tei-council] TEI Conformance

Daniel O'Donnell daniel.odonnell at uleth.ca
Wed Nov 22 09:44:15 EST 2006


To the extent that it matters, I'm finding Conal's reasoning here
persuasive. Is it necessary that the "private" TEI extension namespaces
be labeled as tei extension namespaces. I.e. my namespace for tei
extensions should not simply be danielodonnell.org but
tei.danielodonnell.org so that the space is clearly identified as a TEI
extension namespace (as opposed to all the other things I might us my
general namespace for) and also mine (to avoid collisions). This might
help the incubating idea, because it would clearly mark out the TEI
interesting material.

Not a great namespace expert though, so maybe this is just silly.

-dan

On Thu, 2006-11-23 at 03:38 +1300, Conal Tuohy wrote:
> Hi James
> 
> I can see what you're saying, but I still think a single "TEI Extension" namespace would be a mistake, and I'll explain why.
> 
> Firstly, if people want to define elements for "private use" only, i.e. ruling out interchange altogether, then it doesn't matter what namespace they use - even the main TEI one, or better yet, none at all. If the document is never interchanged then it doesn't really matter what they do.
> 
> However, if the document is ever to be interchanged then it's important that names don't collide, and if we encourage shared use of an extension namespace then we'd have to manage that namespace to avoid name collisions. I don't see what that gives us except extra administrative work. 
> 
> I think it would be very odd to say (even in big letters) "this is a special namespace in which name collisions are only to be expected", because the avoidance of namespace collisions is literally the only purpose of XML namespaces. The analogy with Unicode's Private Use Area is not valid, since Unicode only needs the PUA because it lacks namespaces. 
> 
> Where name collision is considered tolerable, I think it would be better to define extensions in no namespace at all, because at least there's a universal recognition that non-namespaced elements are prone to collision. If a user doesn't care to protect their customisation against name collision then let them not use namespaces.
> 
> Finally, can I ask: what's the actual benefit of defining a special "extension" namespace? It's not like by providing a "TEI Extension" namespace we would save anyone significant work since literally ALL they have to do is make up a unique URI for their namespace.
> 
> I very much like the idea of "incubating" vocabularies and importing them into the core later, but for this to work over the long term I think we will need to be able to incubate each vocabulary independently, in a namespace of its own. 
> 
> Cheers!
> 
> Con
> 
> 
> -----Original Message-----
> From: James Cummings [mailto:James.Cummings at computing-services.oxford.ac.uk]
> Sent: Thu 23/11/06 0:41
> To: Conal Tuohy
> Cc: TEI Council
> Subject: Re: [tei-council] TEI Conformance
>  
> Conal Tuohy wrote:
> > James Cummings wrote:
> > 
> >> And if people were to add their entirely new elements in a different
> >> namespace, then it also makes sense for TEI to suggest a namespace for this
> >> (rather than every user come up with one).
> > 
> > I beg to differ. It seems to me that just because user A and user B having
> > chosen the same name for a new element they have each defined, we are not
> > entitled to assume that the 2 elements are related, which I think would be
> > implied by qualifying them in a generic "TEI Extension" namespace. I think
> > that new elements should always be qualified by namespace URIs belonging to
> > the user defining the elements.
> 
> I recognise that worry and I'm not entirely sure it is misplaced.
> 
> However, I was thinking about the tei-ext namespace as similar to the Unicode
> Private Use area.  If I create a new element tei-ext:article, then I use this
> because it is not docbook:article, and I want to say this is a TEI-like element
> rather than another one.  If you create an element tei-ext:article you are in no
> way saying it is the same semantically to my tei-ext:article.  We would have to
> say in big letters that tei-ext does not guarantee or in any way indicate
> anything about the uniqueness of the elements defined in it.  While I think we
> shouldn't pollute the TEI namespace, I don't think it is wrong to have a
> separate namespace that we encourage people to pollute as long as we are very
> clear that it shouldn't be understood by applications as anything more than that.
> 
> Another option is for a 3fold system:
> 
> - TEI namespace for TEI elements and their equivalents
> - TEI Extension namespace for elements being 'incubated' as possible contenders
> to be TEI elements submitted by members/SIGs/etc As part of a concerted and
> documented proposal
> - MyPersonalNamespace -- user defined namespaces for specific new elements which
> they don't think should become part of TEI
> 
> -James
> 
> 
-- 
Daniel Paul O'Donnell, PhD
Department Chair and Associate Professor of English
Director, Digital Medievalist Project http://www.digitalmedievalist.org/
Chair, Text Encoding Initiative http://www.tei-c.org/

Department of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox +1 403 329-2377
Fax +1 403 382-7191
Email: daniel.odonnell at uleth.ca
WWW: http://people.uleth.ca/~daniel.odonnell/




More information about the tei-council mailing list