Re: XPath 1.0 challenge: select all XML Schema element

> On 24 Jul 2015, at 18:28, 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?
>

None of us can possibly know.

(a) will fail if therebs a user-defined type with local-name bstringb

(b) will fail if there are two different prefixes bound to the XSD namespace.

Normally I would have said (b) is highly improbable; but in fact, itbs not
uncommon to do this, especially in XSD documents: perhaps because the default
namespace is available in element names and QName-valued attributes, but not
in expressions used within xsl:key, xsl:unique, and xsl:assert.

Incidentally neither expression correctly handles an @type attribute that
contains leading or trailing whitespace - but Ibve only ever seen that in
artificial test cases.

Generally, user-written code that attempts to extract information from schema
documents without putting them through a real schema compiler is rife with
such errors. Itbs a similar crime to parsing XML using regular expressions
rather than an XML parser. But if you only want code that works most of the
time, itbs fine.

Michael Kay
Saxonica