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: URI Templates syntax


FYI, posted to the WebFinger list, but equally relevant here. Feedback requested. As for the '%' vs. '+' issue, I have reached out to Roy and will report back.

---

There are two main issues with the use of URI templates:

* The richness of the vocabulary
* The complexity of the template syntax

Currently WebFinger is using a small subset of the default host-meta vocabulary (uri, userinfo, host). Since the two additional variables (other than uri) are trivial to implement (since the client must parse the identifier anyway to get the host), this is not an issue.

There is a potential issue with the template syntax. Roy Fielding recently posted his proposal for a new URI template syntax:

http://uri-templates.googlecode.com/svn/trunk/spec/draft-gregorio-uritemplate.xml

This proposal is significantly more complex/rich than the current {var} / {%var} proposal in XRD. It is also incompatible with the current use of the '%' operator. Roy's draft uses '+' for the same operations (while '%' is used to indicate an array variable).

I strongly believe that whatever we use for WebFinger / XRD should be compatible with the likely syntax coming out of the IETF as a future standard. That will mean code for the more complex syntax (which is likely to be supported in the future in most platforms) will be able to process our templates as-is. If that means changing the '%' to '+', I am fine with that.

Another option is not to use any operators at all, and have the spec define two versions of each variable. For example {uri} is the raw string and {uri-enc} is the encoded string. This is ugly both in prose and code, but removes any issues of operators incompatibility. I am not in favor of such approach (but listing it for the sake of completeness).

Since it would be best for WebFinger *not* to define its own template syntax or vocabulary, and simply inherit the defaults defined for host-meta, I would like to request feedback from people on this topic before I publish the new draft-hammer-discovery draft which defines host-meta.

EHL




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