[tei-council] Another issue with @pattern

O'Donnell, Dan daniel.odonnell at uleth.ca
Sun Jun 7 19:40:19 EDT 2009


Good point about the namespaces, James. I agree that we need both something like your language in the prose and examples.

I hate to say it, since it will turn everybody off, but I think that this (locus and pattern) is as important a development as choice. So let's get it right.

-dan

-----------
Daniel O'Donnell
University of Lethbridge
(From my mobile telephone)

--- original message ---
From: "James Cummings" <James.Cummings at oucs.ox.ac.uk>
Subject: [tei-council] Another issue with @pattern
Date: June 7, 2009
Time: 4:48:3 


All of the examples of pattern so far have been namespace agnostic.

Is it worth specifying that namespace local prefixes are relative to the 
document in which the pattern appears?

<certainty pattern="//figure/svg:*" locus="value" degree="0.2"/>

Since the TEI namespace is declared as the default namespace for any TEI 
document it has no local prefix.  So here I'm talking about the 
certainty I have about the encoding of SVG elements I've embedded inside 
  TEI figure elements.

Where @pattern differs from using an XPointer in @target, is that in 
order to talk about TEI elements by name in an XPointer you must declare 
the namespace that you are talking about in the XPointer itself which 
creates a very verbose string much longer than the examples where we've 
used fragmentary @xml:id references or asterisks.

But the benefit of this in the @target attribute is that it remains 
consistent to some degree when that document (or part thereof) is 
embedded inside another.

Let's say we have a certainty pattern of //title.  Inside a TEI document 
where the TEI namespace is default this creates no problem.  If we then 
embed that document inside a METS containerization we might end up 
pointing to title elements we didn't intend to.  I'm not trying to shoot 
down an idea that I'm partly responsible for encouraging, but I do think 
we need to be careful that we aren't ignoring namespace problems.  We 
can do this by including some examples that point to named elements 
rather than just attributes or asterisks.  Moreover it would be a very 
good idea to include a bit of prose either in the chapter or @pattern 
spec which says something akin to:

"Elements which appear in the pattern with no local namespace prefix are 
assumed to be in the TEI namespace since that is the default namespace 
for TEI documents. Other local namespace prefixes used in a pattern must 
be declared in the document in which the pattern appears. Care must be 
taken when embedding TEI documents inside others where the TEI namespace 
is no longer the default."

Except maybe phrased better.

-James
(Devil's advocate for hire)

-- 
Dr James Cummings, Research Technologies Service, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk
_______________________________________________
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council


More information about the tei-council mailing list