Re: XPath 1.0 challenge: select all XML Schema element

An solution that works "most of the time" can be accepted if a) its failure
will show itself and b) users are willing and able to deal with a.
-W

On 24 July 2015 at 19:45, Michael Kay mike@xxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>
> > 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