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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XPath 1.0 challenge: sele, Wolfgang Laun wolfga | Thread | Re: [xsl] XPath 1.0 challenge: sele, David Carlisle d.p.c |
Re: [xsl] XPath 1.0 challenge: sele, Wolfgang Laun wolfga | Date | Re: [xsl] XPath 1.0 challenge: sele, David Carlisle d.p.c |
Month |