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(_at_)saxonica(_dot_)com <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
On 24 Jul 2015, at 18:28, Costello, Roger L. costello(_at_)mitre(_dot_)org <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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 there’s a user-defined type with local-name “string”
(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, it’s 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 I’ve 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. It’s 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, it’s fine.
Michael Kay
Saxonica
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--