OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] Some questions: Metadata Rels and Host-meta use case


Breno, it is a good point that in XRD 1.0, link processing looks so simple that the nuances of how it will actually work when there is more than one rel in a link, or when the same rel appears in multiple links, is much more important than it might appear. My gut feel is that you are right, the spec should supply guidance around this topic. But my main question is: what is that guidance? Does this guidance only apply if XRD consumers are not smart enough to process both rels in a link? Shouldn't there be guidance to XRD consumers to be prepared for more than one rel in a link?

It also makes me think we really want to have an "XRD Best Practices" forum where these things get ongoing discussion by the community of implementers after the spec is in CD.

=Drummond

On Wed, Sep 23, 2009 at 8:30 AM, Breno de Medeiros <breno@google.com> wrote:
I don't disagree with your perspective, I am just saying that I think
it will be a common case for an applicaiton to look for both a more
generic rel and a broader rel (hoping that additional information will
be available by fetching this broader rel).

In this case, it would be useful to give guidance on the XRD spec on
how to order links. It could be very simple:

E.g.: It is NOT RECOMMENDED (or maybe one SHOULD NOT) include two rels
in a single link where one of the rels is a refinement of the other.
Instead, It IS RECOMMENDED/ (or maybe one SHOULD) create two link
entries for the same URI, ensuring that the more specific rel is
listed first.


On Tue, Sep 22, 2009 at 10:45 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> This issue is more about poor application design than about the XRD architecture. This is the main issue with using the short, registered relation types, which by definition are meant to define a general purpose relation. 'describedby' is so generic, that trying to write predictable application on top of that is going to be hard.
>
> Instead, my view is that the generic relation types should be used to declare common semantics (like 'describedby', 'next', 'prev', etc.) but get used in specific processing rules only if the application is certain that they cannot be used within the same context for something else. What this means is that due to the generic nature of host-meta, it doesn't make sense to put processing requirements on 'describedby' other than use it to label endpoints that provide 'information about'.
>
> This is why for WebFinger we have decided to use two rels, 'describedby' to indicate the general semantic of the relation, and 'http://webfinger.net/rel/acct-desc' for the processor. So in WebFinger, you look for the acct-desc rel value, but if you have a client that is just looking around looking for whatever metadata it can find, the 'describedby' would be useful. It can also help clients figure out something about an unknown relation type, by recognizing some of its other rels.
>
> What is important to remember and focus on is that we know how to use the link framework and XRD for our use cases. It doesn't mean we have everything else figured out, nor should we.
>
> There is a long discussion going on about the Web Linking draft and the point in having a cross media rel registry. The PubSubHubbub folks have been trying to register 'hub' as a relation type in ATOM and define it to be protocol specific. So this is still very much an open debate about the point in registered short rel values. If you are writing an application with very specific processing instructions and use common media types (especially ones shared across multiple protocols such as host-meta), you probably want to use a protocol specific rel value.
>
> This is why I have been talking for the past few months about moving away from the LRDD proposal and simply defining host-meta. I am not sure what value there is in using a common rel value like 'describedby' for building applications with specific processing rules (which is my main focus). I hope the next draft will clarify all this and provide sufficient guidelines about how host-meta should be used.
>
> EHL
>
>
>
>
>
>> -----Original Message-----
>> From: Breno de Medeiros [mailto:breno@google.com]
>> Sent: Tuesday, September 22, 2009 5:00 PM
>> To: xri@lists.oasis-open.org
>> Subject: [xri] Some questions: Metadata Rels and Host-meta use case
>>
>> Because of well-known use case needs, such as host-meta, which were
>> left out of the core spec, it is likely that applications will
>> implement meta-data type rels. For instance, consider a host-meta that
>> wants to delegate the OP endpoint to some other site, but additional
>> metadata to somewhere else:
>>
>>
>> <Link>
>>   <Rel>http://openid.net/op-metadata</Rel>
>>   <URI>https://foo.com</URI>
>> </Link>
>> <Link>
>>   <Rel>'described by'<Rel>
>>  # other stuff goes here
>>   <URI>http://bar.com</URI>
>> </Link>
>>
>> Now, if the client is some greedy protocol like webfinger, that is
>> looking for all meta-data, it will match on everything that is labeled
>> meta-data-y, i.e., will look for 'described by' only. So it will not
>> learn the openid endpoint (it does not know the openid-specific
>> metadata pointer).
>>
>> So, to fix webfinger, the site changes the host-meta to:
>>
>> <Link>
>>   <Rel>http://openid.net/op-metadata</Rel>
>>   <Rel>'described by'<Rel>
>>   <URI>https://foo.com</URI>
>> </Link>
>> <Link>
>>   <Rel>'described by'<Rel>
>>  # other stuff goes here
>>   <URI>http://bar.com</URI>
>> </Link>
>>
>> But this does not have the anticipated effect. The reason is that
>> non-greedy clients looking for specific metadata will only fetch the
>> first element with 'described by' per typical processing rules (since
>> the more specific metadata type is not listed). So that doesn't work
>> either.
>>
>> So the site will have to edit the document to:
>>
>> <Link>
>>   <Rel>http://openid.net/op-metadata</Rel>
>>   <URI>https://foo.com</URI>
>> </Link>
>> <Link>
>>   <Rel>'described by'<Rel>
>>  # other stuff goes here
>>   <URI>http://bar.com</URI>
>>   <URI>https://foo.com</URI>
>> </Link>
>>
>> Moral of the story: It is not clear how processing rules and Rels that
>> have inclusion characteristics (i.e., all foo of relA are also of
>> relB) play together with processing priority rules.
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk
>> +1 (408) 212-0135 (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>



--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]