[tei-council] Another issue with @pattern

[Lou Burnard]

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.
> 
> -James
> (Devil's advocate for hire)
>