I think I prefer to leave this type without a pattern and specify in the specifications the minimum part of xpath that must be supported. I don't see the validation here being so important. Actually a lot of wrong sentences could validate against this pattern and still not be understood by the implementation. And in the other hand I can imagine an specific project that needs an specific outputFormat and need to to extend the support in pywrapper for xpath.
Javier.
On 03/03/2006, at 15:59, Döring, Markus wrote:
Personally I wouldnt wanna implement anything more than qualified paths to be honest. Its definitely much more work to deal with predicates, relative paths or unknown nesting levels ala //. So couldnt we just use this pattern for validation?
(/([a-zA-Z0-9_-]+:)?[a-zA-Z0-9_-]+)+(@[a-zA-Z0-9_-]+)?
Strings are fine as well, but Id prefer validation in exchange for the lack of extensibility. markus
-----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir- bounces@lists.tdwg.org] Im Auftrag von Renato De Giovanni Gesendet: Freitag, 3. März 2006 02:48 An: tdwg-tapir@lists.tdwg.org Betreff: Re: [tdwg-tapir] conceptual binding
Hi all,
I would be reluctant to force provider implementations to understand more complex XPath patterns without having a clear demand from our community. We obviously need optional namespace prefixes in the pattern since it's already clear that output models may easily mix different namespaces. But I don't know if it's wise to go beyond that.
Adopting the full Location Paths specification seem an overkill, and even the WFS predicates look strange in our context. I did find some examples about using them in WFS:
http://mail.opengeospatial.org/pipermail/wfs-dev/2004- August/000189.html
But it's important to note that WFS uses XPath in a different context. In TAPIR we just use them in the output model mapping section and also to select partial nodes in search templates. TAPIR filters don't reference XML nodes, they reference concepts (which have a completely different type).
Back to XPath predicates, maybe someone could want to get back only the "n" identification of an ABCD unit, for instance. So I can imagine situations when <partial> could make use of predicates, but for me the cost-benefit still doesn't seem to justify the additional complexity. And it's hard to believe that someone could really want to map only the "n" occurrence of a specific XML element in an output model. But maybe I'm wrong...
Javier's suggestion to remove the SimpleXPathType restriction and only describe in the specs the minimum patterns to be understood by providers seems reasonable. We could even allow provider implementations to understand more complex patterns if they want.
Regards,
Renato
On 3 Mar 2006 at 13:04, Javier de la Torre wrote:
Hi Markus,
No. I was just thinking in adding something like Location Paths (http://www.w3.org/TR/xpath#location-paths) or we could make use of what the OGC defines in WFS:
From WFS specifications (1.0.0 and 1.1.0)
""" This specification does not require a WFS implementation to support the full XPath language. In order to keep the implementation entry cost as low as possible, this specification mandates that a WFS implementation must support the following subset of the XPath language:
- A WFS implementation must support abbreviated relative location
paths. 2. Relative location paths are composed of one or more steps separated by the path separator '/'. 3. The first step of a relative location path may correspond to the root element of the feature property being referenced or to the root element of the feature type with the next step corresponding to the root element of the feature property being referenced. 4. Each subsequent step in the path must be composed of the abbreviated form of the child:: axis specifier and the name of the feature property encoded as the principal node type of element. The abbreviated form of the child:: axis specifier is to simply omit the specifier from the location step. 5. Each step in the path may optionally contain a predicate composed of the predicate delimiters '[' and ']' and a number indicating which child of the context node is to be selected. This allows feature properties that may be repeated to be specifically referenced. 6. The final step in a path may optionally be composed of the abbreviated form of the attribute:: axis specifier, '@', and the name of a feature property encoded as the principal node type of attribute. """ In the WFS schema there is a type called XlinkPropertyName to care of this, but I don't know if this is suitable for us...
The other possibility is to set it to xsd:string and in the documentation explain that the implementation is free to define up to which level they want to support Xpath there and maybe define the minimum as we had before.
Javier.
On 3/3/06, "Döring, Markus" m.doering@bgbm.org wrote:
Well, what do you consider a proper xpath type? I think we can add some basic things to our simple pattern. But are you also thinking of adding different axes, functions and all this? Things I could see to be allowed are:
(pre:)qname Selects all child nodes named like this (optionally qualified with prefixes) / Selects from the root node // Selects nodes in the document from the current node that match the selection no matter where they are .. Selects the parent of the current node @ Selects attributes Predicates: [i] Select ith node [last()-1] Select second-last node [position()<3] Select all nodes before the third
But that already means we could get a list of matching nodes from the xpath. So a simple mapping becomes a mapping to a list of nodes - essentially multiple single mappings. Gregor was actually looking for this in the recursive SDD.
Is this overkill already? Markus
-----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Javier privat Gesendet: Donnerstag, 2. März 2006 19:48 An: Renato De Giovanni Cc: tdwg-tapir@lists.tdwg.org Betreff: Re: [tdwg-tapir] conceptual binding
Hi,
Now looking at the "simpleXPathType" (used by the node's path attribute) it seems that the string restriction does not allow for namespace prefixes. So I guess this is something that needs to be fixed in the schema.
Actually the problem with the simpleXpathType arise when I did the example outputModel, it does not validate against the schema because I used ns prefixes.
Maybe my sentence was incorrect, I wanted to say "The change in the mapping section is only in allowing (forcing?) qualifies paths in the node element"
Actually I think pywrapper would not complain of the lack of ns prefixes there (probably the other way around :D ), but in the unlikely event that the ns resolve ambiguities then we are in troubles.
And actually I don't know why this path can not be an xpath. pywrapper and Digir will not be able to undertand complicate xpaths, but maybe other implementations can, and I don't see what is the problem if the provider arise and error like "Sorry xpath in the mapping section of the outputModel not understood".
Imagine a TAPIR implementation that allows you to do a mapping to the second element </a>using xpath expressions. We would be able to do mappings to structures like:
<a> <b/> <b>content here</b> </a>
So here is my proposal: change the simpleXPathType to a proper XpathType.
Javier.
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org