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

Sat Apr 28 09:54:19 EDT 2012

Everyone,

This is our third attempt in nine months. (I think better has become the enemy of good enough.) 

DCP-4 is up for a vote, so I encourage folks to cast your votes yea or nay. If there are enough nay votes by people who have a better alternative or think someone else has one, then we will go back around....
--
Christopher Lynnes, NASA/GSFC
301-614-5185
________________________________________
From: Stephen Richard Azgs [Steve.Richard at Azgs.AZ.gov]
Sent: Saturday, April 28, 2012 1:30 AM
To: Lynnes, Christopher S. (GSFC-6102); Huang, Thomas
Cc: esip-discovery at lists.esipfed.org
Subject: Re: [Esip-discovery] FW: [spg] OGC Xlink Policy and timeline to move to        XLink 1.1

In my opinion, services should be identified using URIs; ideally the service specification would define the identifier, which would specify the version and the base spec. We need a registry of such identifiers. OGC is seeing up such a registry. Perhaps ESIP could host another one for 'orphan'specs.
Near in mind that for some services, knowing the base spec and version is not enough for interoperability; a client trying to use the link may also need a URI for a profile. -------- Original Message -------- From: Lynnes, Christopher S. (GSFC-6102) Sent: Fri, 27/04/2012 11:51 AM To: Huang, Thomas CC: esip-discovery at lists.esipfed.org Subject: Re: [Esip-discovery] FW: [spg] OGC Xlink Policy and timeline to move to XLink 1.1

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 element. The 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 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

_______________________________________________
Esip-discovery mailing list
Esip-discovery at lists.esipfed.org
http://www.lists.esipfed.org/mailman/listinfo/esip-discovery