[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?
> Strings are fine as well, but Id prefer validation in exchange for
> the lack of extensibility.
> -----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:
> 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.
> 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
>> 1. A WFS implementation must support abbreviated relative location
>> 2. Relative location paths are composed of one or more steps
>> 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
>> 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.
>> 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
>>> [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?
>>> -----Ursprüngliche Nachricht-----
>>> Von: tdwg-tapir-bounces at lists.tdwg.org
>>> [mailto:tdwg-tapir-bounces at lists.tdwg.org] Im Auftrag von Javier
>>> 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
>>>> 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
>>> 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:
>>> <b>content here</b>
>>> So here is my proposal: change the simpleXPathType to a proper
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
More information about the tdwg-tag