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


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



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