[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] XPath 1.0 challenge: select all XML Schema element declarations with type string


Subject: Re: [xsl] XPath 1.0 challenge: select all XML Schema element declarations with type string
From: "Wendell Piez wapiez@xxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 24 Jul 2015 17:58:49 -0000

Roger,

We can go further, and identify the risk factors for the proposed non-solution:

1. It will fail if the schema is a correct schema conformant to the
schema for schemas, but has more than one prefix bound to the schema
namespace, raising the possibility that xs:element and the string type
named in its attribute have different prefixes despite being both XSD.

Whether it is acceptable for "can't do this one" to be a result of
your query is a different question. In any case, that query (is more
than one prefix bound to a given namespace) is also no cinch in XPath
1.0.

But here is XPath 1.0 to return a set of elements including all the
risky cases (it returns any datatype not bound to the xs namespace as
well as those bound to XSD types using a different prefix from the
element name):

//xs:element[not(starts-with(@type,substring-before(name(),'element'))]

Note that even this does not solve the problem: it merely helps manage
it by detecting where the regularity (on which the other test depends)
does not apply.

2. It will fail -- all bets will be off -- if the schema is not
conformant to the schema for schemas, in which case it is an arbitrary
XML document and we do not know if it needs (for example) to fail to
return <xs:elementThing type="xs:string"/> from the query (which it
will).

If you know your documents will never fall into either of these
categories, you can probably have more confidence.

Also note that if you can exclude 2, you should never get any false
hits ... just perhaps misses from documents in case 1.

And it is precisely because these are all external contingencies --
what sorts of risks are you actually taking -- that this is the kind
of approach that could work for a local process, but is categorically
not fit for a general solution (or even much discussion in polite
company).

Cheers,
Wendell


On Fri, Jul 24, 2015 at 1:28 PM, Costello, Roger L. costello@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> Thanks for the outstanding responses.
>
> Let's summarize:
>
> 1. The problem cannot be solved in XPath 1.0.
>
> 2. XPath 1.0 is not "relationally complete" in Codd's sense.
>
> 3. The following two XPath expressions come close to solving the problem. However, sometimes they return an element which should not be returned and sometimes they don't return an element which should be returned.
>
> (a) //xs:element[(@type = 'string') or (substring-after(@type, ':') = 'string')]
>
> (b) //xs:element[@type= concat(substring-before(name(),'element'),'string')]
>
> I must use XPath 1.0.  So which of those two XPath expressions would you recommend I use?
>
> Michael says that (b) is a 99.9% solution. Is (a) less than, greater than, or equal to 99.9%? That is, which of (a) or (b) will work correctly most often?
>
> /Roger
> 



-- 
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^


Current Thread
Keywords