[tdwg-tapir] conceptual binding

Javier de la Torre jatorre at gmail.com
Mon Mar 6 11:29:34 CET 2006

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.


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 at lists.tdwg.org [mailto:tdwg-tapir- 
> bounces at lists.tdwg.org] Im Auftrag von Renato De Giovanni
> Gesendet: Freitag, 3. März 2006 02:48
> An: tdwg-tapir at 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:
>> 1. 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 at 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 at lists.tdwg.org
>>> [mailto:tdwg-tapir-bounces at lists.tdwg.org] Im Auftrag von Javier
>>> privat
>>> Gesendet: Donnerstag, 2. März 2006 19:48
>>> An: Renato De Giovanni
>>> Cc: tdwg-tapir at 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 at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
> _______________________________________________
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org

More information about the tdwg-tag mailing list