[tdwg-tapir] conceptual binding
m.doering at BGBM.org
Fri Mar 3 10:39:45 CET 2006
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?
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
> 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:
So here is my proposal: change the simpleXPathType to a proper
> Best Regards,
> On 2 Mar 2006 at 17:11, Javier de la Torre wrote:
>> Did I understand this incorrectly?
>> The change in the mapping would only be qualifying concepts in the
>> path attribute not in the concept ids.
>> I think we agree on that the concept ids does not have anything to do
>> with XML schema or Xpaths no? Is just "by coincide" that we are using
>> something "similar".
>> On 3/3/06, Renato De Giovanni <renato at cria.org.br> wrote:
>>> Hi Markus,
>>> This is really good news for the PyWrapper!
>>> Now concerning your question, I think we should really try to avoid
>>> defining concepts with compound XML schemas. It's a lot cleaner and
>>> more elegant using gcp#accession/FullScientificName to map local
>>> databases and to use in filters. As you said, the WFS response would
>>> just be one of the possible output models making use of the
>>> The real xpaths to WFS elements (including namespaces) would only be
>>> used in the output model mapping section:
>>> <concept id="gcp#accession/FullScientificName"/>
>>> Best Regards,
>>> On 28 Feb 2006 at 11:38, "Döring, Markus" wrote:
>>>> I recently added support for schema imports in pywrapper mainly
>>>> to support multiple namespaces in the repsonse.
>>>> Me (and Javier) wanted to allow something like this:
>>>> <gcp:accession fid="accession.12">
>>>> <gcp:FullScientificName>Quercus ilex</
>>>> Here comes my problem:
>>>> How do we refer to the FullScientificName concept in TAPIR?
>>>> As a convention for schemas we said to create the fully
>>>> qualified concept from the namespace and the simple xpath to the
>>>> element. So somethinkg like this:
>>>> A real xpath to that element would of course include several
>>>> Could it be that we never need to refer to "compound" concepts
>>>> anyway? A provider would probably map his db to the GCP schema
>>>> alone. The WFS response is only the responded view/data model
>>>> and we would still just use gcp#accession/FullScientificName as
>>>> the qualified concept in filters. This is also true for our
>>>> simple extension schemas I think (EFG for ABCD, all extensions
>>>> for DwC). But arent there other cases?
> 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