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

[Lynnes, Christopher S. (GSFC-6102)]

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...
--
Dr. Christopher Lynnes, NASA/GSFC, Code 610.2, 301-614-5185