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: URITemplate

(combining multiple posts)

> 1. Do we need URITemplate support in XRD, or could this be a host-meta
> extension?

While the immediate use case is host-meta, there are other use cases such as OpenSocial which has invented its own template element in XRDS. While host-meta is very useful, other similar host/site/domain documents are likely to be added in the future and they are likely to need such an element.

But I think we are going to see use for this element in the social space pretty fast if it is widely adopted in libraries. For example, consider an API that lets you ask for all of my friends, and then for more information about each friend. This is not a site level information but something specific to a particular service. That service can have an XRD:


This isn't that complicated and pretty useful. It is also pretty well defined and works for documents other than host-meta. This is in line with how OpenSocial proposed to use templates.

So I believe having XRD include a template element is generally useful and furthermore, it is unlikely that this element will be successful anytime soon without making it a core part of the specification.

> Should in this case <Link> call for '1 or More' URI's? Right now, it
> calls for '0 or More', but without either a URI or URITemplate it is
> not clear what purpose a <Link> element might serve.
> Is a <Link> valid with 0 <URI> and 0 <URITemplate> children?
> Is a <Link> valid with 0 <Rel> children? What is the meaning of such a
> <Link>?

As currently defined, and without any extensions, a <Link> without <URI> or <URITemplate> is undefined. However, we should not prevent other extensions from defining their own method of providing a URI for the target, just like we have done with the two built-in options. So both elements must be allowed to appear 0 or more times. The same goes for a <Link< without a <Rel>. It is currently undefined but there is little value in preventing extensions or protocols from coming up with their own way of using it.

We are purposely and explicitly leaving a lot of thing undefined.

> 2. If we need URITemplate, do we need extensible vocabularies? (That
> is what the spec calls for).

As opposed to the specification defining a vocabulary? The vocabulary is completely <Rel>-dependent. Applications that use templates must define their vocabulary and they way it is declared in the link is using the <Rel> value. Consider OpenSocial and the example above, the host-meta vocabulary will be completely irrelevant there. Not all templates are used for URI transformation.

> 3. Do we need to specify the processing order for URI vs. URITemplate?
> Presumably the discovery is for either the subject or some other
> resource related to the subject, but not both. Should not this be a
> client prerrogative?

There are two ways to think about this. One is to say these are completely different elements which will be used very differently by applications and therefore should be treated differently. Another is to say that both produce (one directly and the other after processing) a target URI, and those URIs should be kept in the complete order of the elements, regardless of where they are coming from.

I am happy to go with either position. The lack of use cases for a <Link> with both suggests we should go with the first view and remove the combined priority ordering.


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