[Esip-discovery] FW: [spg] OGC Xlink Policy and timeline to move to XLink 1.1

Huang, Thomas (388J) Thomas.Huang at jpl.nasa.gov
Fri Apr 27 14:50:16 EDT 2012


Hey Chris,

I understand.  It seems the DCP-4 is requiring either one or both

1. the 'http://xml.opendap.org/.../' as the standard xlink value for OPeNDAP.  This must be explicitly stated on the spec.
2. the word OPeNDAP must be part of the title. 

Looking at this beyond just the OPeNDAP, the concern for using #1 to determine what the linked resource is
- xlink is not an required attribute
- what happen if a search provider decides to clone dap2.xsd under their own domain?
- for non-standard services parsing the URL substring may not be a good method to determine the linked resource

#2 might be a better solution, but we should provide a list of recommended keywords for describing linked resources.

I am looking for interoperability and portability for DCP search clients.  I would like to be able to implement a single search client according to the DCP spec, connect to all DCP-compiliant service, and reliability identify resource links for OPeNDAP, distribution link, metadata, etc.


thanks,

Thomas.

On Apr 27, 2012, at 9:51 AM, Lynnes, Christopher S. (GSFC-6102) wrote:

> 
> On Apr 26, 2012, at 4:58 PM, Huang, Thomas (388J) wrote:
> 
>> Hey Chris,
>> 
>> DCP-4 seems to work fine for describing OPeNDAP rel link.  My only concern has to do with efficiency.  The presented paradigm suggests using xlink to describe the linked resource/service.  This means the client really has to load the xlink resource and interpret it
> 
> Actually, our client is not going to load the xlink resource.  We're just going to test against the contents of the xlink attribute.  If $link->attribute eq 'http://xml.opendap.org/dap/dap2.xsd', then proceed to interact with it as OPeNDAP. There is no need to dereference the xsd.  I don't really see a major difference between
> 
> if ($link->attribute eq 'http://xml.opendap.org/dap/dap2.xsd')
> and
> if ($link->title =~ /opendap/i)
> 
> Indeed, in this case, you could even do:
> 
> if ($link->attribute =~ /opendap/)
> 
> and achieve the same effect.  Now there is literally no difference between the two.
> 
>> , in order to deterministically figure out what this linked resource is.  From a completeness point of view, I think this model should cover most cases.  Coming for the user point of view, this seems to suggest for each link in the OpenSearch response they might also have to make an additional call (http) in order to find the link of their interest.  This could be very slow.  For completeness we should use this paradigm, but for efficiency we should consider recommending some common resource keywords the service providers could use in the 'title' attribute to help them quickly identify what is the link.
>> 
>> thanks,
>> 
>> Thomas.
>> 
>> 
>> On Apr 26, 2012, at 11:59 AM, Lynnes, Christopher S. (GSFC-6102) wrote:
>> 
>>> 
>>> On Apr 26, 2012, at 1:55 PM, Huang, Thomas (388J) wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> Looking at the attributes and values for rel, type, and xlink, it is difficult to determine the href is really pointing to an OPeNDAP server.
>>>> Perhaps we should consider the keyword OPeNDAP be the prefix for the title attribute?
>>> 
>>> Thomas,
>>> Actually, the xlink is meant to serve that purpose:  xlink:role="http://xml.opendap.org/dap/dap2.xsd" is meant to *unambiguously* say that the href is pointing to an OPeNDAP server. Can you elaborate on where the difficulty arises?
>>> 
>>> 
>>>> Using the title value and type attribute, the user applications/services should be able to programmatically determine how to connect to the href defined by the <link/> element.  The <link/> element could be used to point to other relevant services such as FTP, SFTP, metadata conversion service, extraction/subsetting services, etc.  Should we consider standardizing some of the URL title/keywords?
>>>> 
>>>> 
>>>> thanks,
>>>> 
>>>> Thomas.
>>>> 
>>>> On Apr 26, 2012, at 10:23 AM, Hua, Hook (388C) wrote:
>>>> 
>>>>> FYI. Relevant for DCP-4: OPeNDAP Links in the Atom <link/> element
>>>>> http://wiki.esipfed.org/index.php/DCP-4
>>> 
>>> 
>>> --
>>> Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185
>>> 
>>> 
>> 
>> --
>> Thomas Huang
>> Jet Propulsion Laboratory
>> 4800 Oak Grove Drive, Mail Stop 171-264, Pasadena, CA 91109
>> Phone: 818.354.2747, Cell: 626.318.4637, Email: thomas.huang at jpl.nasa.gov
>> 
>> DISCLAIMER: All personal and professional opinions presented herein are my own and do not, in any way, represent the opinion or policy of JPL, NASA or Caltech.
>> 
>> 
>> 
>> 
>> 
> 
> --
> Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185
> 
> 

-- 
Thomas Huang
Jet Propulsion Laboratory
4800 Oak Grove Drive, Mail Stop 171-264, Pasadena, CA 91109
Phone: 818.354.2747, Cell: 626.318.4637, Email: thomas.huang at jpl.nasa.gov

DISCLAIMER: All personal and professional opinions presented herein are my own and do not, in any way, represent the opinion or policy of JPL, NASA or Caltech.







More information about the Esip-discovery mailing list