[Esip-discovery] RFC ready for internal review by Nov. 9

Thu Oct 11 12:14:47 EDT 2012

On Oct 11, 2012, at 8:38 AM, Lynnes, Christopher S. (GSFC-6102) wrote:

>
> On Oct 10, 2012, at 6:31 PM, Pedro Gonçalves <pedro.goncalves at terradue.com> wrote:
>
>>> On the parsing aspect, I don't think it is necessary to extract the end part of the path to get the version, 1.2.  I think you can consider the whole string to be "the version".  In which case, the xpath is once again pretty easy.  This may also be useful in distinguishing between, say, an OGC-compliant OpenSearch "version" and an ESIP-compliant OpenSearch "version".
>>>
>>
>> in the case of ESIP conventions we do not have elements that we want to extract and it might be my fault but is I think is not that straightforward to ask a XSLT processor using Xpath 1.0 the question "is a given namespace written in the file"  while we don't have any XML element actually using that namespace.
>> (this is easy for an human or a simple string processor but the fact is not that obvious on a xml processor)
>>
>> Also I'm not a XML/Xpath expert and I might have missed some XML 101 classes but I don't know the function [1] that gives us that and even if it exists it will force as to ask subsequently the different versions that we support. This means that we would need to ask
>> - does this namespace exists in the file http://commons.esipfed.org/ns/discovery/1.2/
>> if not then
>> -  does this namespace exists in the file http://commons.esipfed.org/ns/discovery/1.3/
>> and so on ...
>>
>> This said I might be missing something and you have already found a way to solve this issue
>>
>> regards
>>
>> Pedro
>
> Hmmm…actually the plan was to conventionalize (v. standardize) the prefix we use for the namespace as well, so that one would look for the value of the namespace attribute 'esipdiscovery'.  But now I'm not so sure we have access to that, as it is in the XML header, not the body, so I will need to try a quick prototype…
>

OK, here are some findings:
(1) When I went back to www.opensearch.org<http://www.opensearch.org> for an example Atom response, I found this:

<?xml version="1.0" encoding="UTF-8"?>
 <feed xmlns="http://www.w3.org/2005/Atom"
       xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/">
   <title>Example.com Search: New York history</title>

So our esipdiscovery namespace formulation, i.e.,

<?xml version="1.0" encoding="UTF-8"?>
 <feed xmlns="http://www.w3.org/2005/Atom"
       xmlns:esipdiscovery="http://commons.esipfed.org/ns/discovery/1.2/"
       xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/">
   <title>Example.com Search: New York history</title>

is really just following the versioning pattern already used by OpenSearch.

(2) OTOH, it is hard for a client to extract the namespace value with XPath for xmlns:esipdiscovery, because parsers may apply the namespace in parsing the XML prior to providing a response to an XPath call. I verified this with a simple Perl program and XML file:

An xpath of feed/@xmlns:esipdiscovery gives no result. :-(

(3) There is an interesting treatment of versioning, namespaces and XPath at: http://msdn.microsoft.com/en-us/library/ms950779.aspx (scroll down to XML Namespace Caveats).

They note that W3C uses the namespace method, while some use a simple version attribute on the root element. The former is especially key for cases where the semantics are expected to change with version, which can happen in our case.

(3a) The key finding may be that XSLT actually uses BOTH mechanisms for specifying version.

(4) Now we can't put simply the version attribute in that root element, because the version would be misconstrued as an Atom version.
But we could follow the XSLT model with the following in the Atom response:

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
       xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/"
       xmlns:esipdiscovery="http://commons.esipfed.org/ns/discovery/1.2/"
       esipdiscovery:version="1.2">
</feed>

This DOES produce an XPath result for feed/@esipdiscovery:version.  So now the clients are happy.

WHat do you all think about adding this version to the Atom response along with our namespace-based version string?
--
Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-discovery/attachments/20121011/b25a3408/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xpath.pl
Type: text/x-perl-script
Size: 367 bytes
Desc: xpath.pl
URL: <http://www.lists.esipfed.org/pipermail/esip-discovery/attachments/20121011/b25a3408/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ns.xml
Type: application/xml
Size: 234 bytes
Desc: ns.xml
URL: <http://www.lists.esipfed.org/pipermail/esip-discovery/attachments/20121011/b25a3408/attachment.xml>