[tdwg-tapir] conceptual binding
Javier de la Torre
jatorre at gmail.com
Thu Mar 2 19:48:10 CET 2006
> 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
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
More information about the tdwg-tag