param-link-to-field

[François Bonnarel]

Hi all,
Le 17/02/2014 18:01, Patrick Dowler a écrit :
>
> Thanks Markus; that clears things up. Since I didn't hear otherwise, 
Sorry I'm still considering the consequences. I will be back ASAP.
> I am going to change the WD to use a child LINK instead of the sibling 
> FIEDLref (with href fragment).
Best regards
François
>
>
> When I do that, I need to explain what content-role="ddl:id-source 
> means. What is that "ddl" prefix looking thing and where is it defined?
>
> Pat
>
> On 14/02/14 02:28 AM, Markus Demleitner wrote:
>> Hi Pat, hi DAL,
>>
>> On Tue, Feb 11, 2014 at 11:10:06AM -0800, Patrick Dowler wrote:
>> [reordered, abridged]
>>>> On 12/12/13 05:04 AM, Markus Demleitner wrote:
>>>> <FIELD name="obs_publisher_did" ID="datalinkID"
>>>>        utype="obscore:Curation.PublisherDID"
>>>>
>>>> <PARAM name="ID" arraysize="*" datatype="char" ucd="meta.id;meta.main"
>>>>        value="">
>>>> <DESCRIPTION>The pubisher DID of the dataset of interest</DESCRIPTION>
>>>> <LINK content-role="ddl:id-source" value="#datalinkID"/>
>>>> </PARAM>
>>>>
>>> Is the ref in FIELDref explicitly defined to be an XML ID value in
>>> the document? Is a LINK value with a fragment explicitly an XML ID
>>> value? Or are one or both just conventions we are adopting?
>>
>> The VOTable spec is not clear on what FIELDref's ref actually is. The
>> (non-normative) Schema says it's of type xs:IDREF; funnily enough,
>> xmlschema-2 then says on this that the "value space of IDREF is the
>> set of all strings that match the NCName production" -- i.e., schema
>> doesn't require referential integrity here.  This may be for the
>> better, as I've never quite wrapped my head around the suggested
>> interaction between XML ids and VOTable IDs.  Anyway, it's clear that
>> the intention is that it's a reference to *some* id within the
>> document.
>>
>> For LINK, ahem, I just realize a bug in my proposal.  The #datalinkID
>> should fairly certainly be in LINK's href attribute rather than in its
>> value attribute.
>>
>> With that, the VOTable XML schema would want us to have an AnyURI,
>> which "can be absolute or relative" (xmlschema-2).  I suppose we're
>> fine there with our fragment identifier (I've not digged down to the
>> actual schema definition, so I'm not 100% sure at this point).  The
>> question of what makes up a fragment in a concrete XML or SGML
>> instance is IIRC up to what's called application in these circles
>> (HTML or VOTable or DocBook or what have you); we're free to say for
>> VOTable, that's defined by ID, but since the VOTable REC doesn't say
>> anything about that, I suppose this counts as a convention at this
>> point.
>>
>>> Is there any particular significance *right now* to the
>>> content-role="ddl:id-source"?  Is this to allow for other LINK(s) in
>>> there that are not so marked? Is this to enable some semantic magic?
>>
>> It is, indeed, to be explicit about this link's role; I do not think
>> it would be wise to clobber the entire LINK element for children of
>> this particular parameter.
>>
>> Clients might use it to discover the parameter in which to pass the
>> ID, but I am convinced we should recommend to just assume the
>> parameter called ID is just that and to refuse the operation of a
>> datalink service where no such parameter is present (dream: compare
>> names case-sensitively -- aahhhh).
>>
>>> We are talking about a set of PARAM elements inside a RESOURCE with
>>> type="service" ... are there any other types of PARAMs than input?
>>
>> The access URL, for one, would come in a param in my scheme.
>> Possibly other stuff that operators want, maybe for custom services.
>>
>> For services having input parameters that happen to be STC roles
>> ("minimal RA", say), there'd be PARAMs within the STC declarations,
>> too, if (bambi eyes) we agree to warmly recommend to helpfully
>> declare STC metadata.  Of course, these are nicely stowed away within
>> a group, too, but I take that as an indication that GROUPing things
>> that are related will help in the evolution of the standard.
>>
>>> Are we intending to allow someone to describe the output parameters
>>> of the service as well? If not, do we really need the GROUP of input
>>> params?
>>
>> On the need: after what I've said above, I'd say yes.  Output
>> parameters: You know, we're experimenting here with making Splat a
>> datalink client, and the fact that, with such a service, the client
>> only has a fairly hazy notion of what it is it'll get back from a
>> service is ugly.  So, I'd be all for a PARAM giving a list of MIME
>> types that can come out of a service, for the sake of simplicity (web
>> things probably know how to parse this) maybe as shown by HTTP
>> content negotiation.  But maybe that's becoming too complex.
>>
>> But the bottom line: Yes, I believe at some point we may want
>> additional service metadata, and some of that may most conveniently
>> go into PARAMs.  I'm not quite as sure if I like the notion of
>> "output params" in this context, but maybe I just don't see an
>> otherwise obvious use case here.
>>
>> My take on this is we need the client writer's input on this; the
>> fact that it's far harder to be sure what's coming back is IMHO one
>> of the two main differences between the old (and I contend somewhat
>> proven) getData hack and the Datalink server-side processing
>> proposal, so it's entirely possible more thought is needed here.
>>
>> Cheers,
>>
>>            Markus
>>
>