[tdwg-tapir] conceptual binding

"Döring, Markus" 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?

-----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


> 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:

	<b>content here</b>

So here is my proposal: change the simpleXPathType to a proper  


> Best Regards,
> --
> Renato
> On 2 Mar 2006 at 17:11, Javier de la Torre wrote:
>> Uhmm...
>> 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".
>> Javier.
>> 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  
>>> concepts.
>>> The real xpaths to WFS elements (including namespaces) would only be
>>> used in the output model mapping section:
>>> <node
>>> path="/wfs:FeatureCollection/gml:featureMember/gcp:accession/ 
>>> gcp:FullS
>>> cientificName">
>>> <concept id="gcp#accession/FullScientificName"/>
>>> </node>
>>> Best Regards,
>>> --
>>> Renato
>>> On 28 Feb 2006 at 11:38, "Döring, Markus" wrote:
>>>> Hello,
>>>> 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:
>>>> <wfs:FeatureCollection
>>>>     xmlns:wfs="http://www.opengis.net/wfs"
>>>>     xmlns:gml="http://www.opengis.net/gml"
>>>>     xmlns:gcp="http://www.ipgri.org/schemas/gcp_passport_gml/1.0">
>>>>     <gml:featureMember>
>>>>         <gcp:accession fid="accession.12">
>>>>             <gcp:GermplasmID>12</gcp:GermplasmID>
>>>>             <gcp:FAOInstituteCode>ES</gcp:FAOInstituteCode>
>>>>             <gcp:FullScientificName>Quercus ilex</ 
>>>> gcp:FullScientificName>
>>>>         </gcp:accession>
>>>>     </gml:featureMember>
>>>> </wfs:FeatureCollection>
>>>> 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:
>>>> http://www.opengis.net/wfs#/FeatureCollection/featureMember/ 
>>>> accession/FullScientificName
>>>> A real xpath to that element would of course include several  
>>>> namespaces:
>>>> /wfs:FeatureCollection/gml:featureMember/gcp:accession/ 
>>>> gcp:FullScientificName
>>>> 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?
>>>> Thanks,
>>>> Markus
> _______________________________________________
> 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

More information about the tdwg-tag mailing list