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

[Pedro Gonçalves]

Hi Chris

thanks for your quick answer ... comments inline

On Oct 10, 2012, at 6:10 PM, Lynnes, Christopher S. (GSFC-6102) wrote:

> On Oct 10, 2012, at 3:39 PM, Pedro Gonçalves wrote:
>> in section 7.2.7 you propose to use the namespace to convey the version of esip conventions being used 
>> but it seems that this XML namespace (esipdiscovery) is not actually used on the query and response XML elements 
>> and it is not easy to XPATH the namespaces list and get the version number  
>> 
>> wouldn't it be better to follow ATOM conventions and use the category element instead?
>> for example at feed level you could use 
>> 
>> <feed>
>> 	....
>> 	<category scheme="http://commons.esipfed.org/discovery/version" term="1.2" label="Version 1.2 of the ESIP Discovery Conventions"/>
>> 	...
>> 	<entry>
>> 		...
>> 	</entry>
>> </feed>
>> 
>> this is much easier to xpath and to quickly obtain the ESIP Discovery version
>> 
>> ciao 
>> 
> 
> Pedro,
>  I actually started by trying to fit the version into the OpenSearch Description Document, and then tried to do the Atom feed response in a similar manner.  The OSDD is actually where the version is most important for the OpenSearch case, because it's likely that the client has parsed that first before issuing any queries to get the Atom feed response.  The main use for version in the Atom feed response is actually for the data casting folks (where there is not necessarily a search preceding acquisition of the Atom feed document.)

the way that the OSDD works is using that a namespace is a way to correctly select the XML elements using xpath and xslt and it works because you are actually selecting elements that originate from a give OpenSearch version (that is the reason why it doesn't change between subversions) 
   
so we use 
xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/"

as a way to select 

<opensearch:Url ...
 
that is in fact equivalent to 

http://a9.com/-/spec/opensearch/1.1/:Url 


>  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 


[1] http://www.w3schools.com/xpath/xpath_functions.asp

>  Datacasting guys, what do you think?  Pedro's suggestion would be closer to what Atom does, but then will be a very different formulation from the one found in the OSDD for OpenSearch...
> 
> 
>> Pedro
>> 
>> 
>> On Oct 10, 2012, at 4:09 PM, Lynnes, Christopher S. (GSFC-6102) wrote:
>> 
>>> OK, think I am maxed out for now until i get some feedback on the ESIP Discovery RFC for the NASA Standards and Processes Group. It would be nice to submit this just before the ESDSWG Meeting, say Nov. 9.
>>> 
>>> Please look for:
>>> o  clarity
>>> o  understandability
>>> o  accuracy
>>> 
>>> If you can suggest (or even supply) more pictures for it, that would be good.
>>> 
>>> Here is the link:  https://docs.google.com/document/d/1ymt5vsP2jw2YMVnc2B8uEI0BKTHcT4jSNVQzruLIFPA/edit
>>> --
>>> Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185
>>> 
>>> 
>>> _______________________________________________
>>> Esip-discovery mailing list
>>> Esip-discovery at lists.esipfed.org
>>> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery
>> 
> 
> --
> Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2002 bytes
Desc: not available
URL: <http://www.lists.esipfed.org/pipermail/esip-discovery/attachments/20121010/5d94b38a/attachment.p7s>