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

["Wolfgang Laun wolfgang.laun@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

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