[tei-council] Another issue with @pattern
lou.burnard at oucs.ox.ac.uk
Mon Jun 8 04:53:28 EDT 2009
Let's not lose sight of the problem we're trying to solve here.
Gabby wants to be able to indicate uncertainty etc. about an attribute
value, using a nice simple syntax.
If the can of worms that @path opens proves to be a pandora's box, then
I propose to withdraw it hastily, and replace it with one or other of
the following less attractive hacks:
a) restore the possibility of specifying that the locus of uncertainty
is an attribute value by allowing for a value of "@" + anyWord on @locus
b) replace @pattern by an ad hoc @attribute attribute
James Cummings wrote:
> 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.
> (Devil's advocate for hire)
More information about the tei-council