Loading ...
Sorry, an error occurred while loading the content.

17958Re: Using URI templates in XHTML

Expand Messages
  • Philippe Mougin
    Nov 10, 2011
    • 0 Attachment
      Eric, Mike,

      Thanks for the insightful remarks.

      Dynamically communicating constraints on allowable values for expansions in a declarative way is sure an interesting problem.
      For m2m interactions, one challenge is that the more stuff we try to communicate dynamically, the more client programs become difficult to implement. So we probably all have to find a good tradeoff depending on our particular contexts. For example, in my current project I have considered using XForms for my hypermedia controls, but it would have been too much complex for the teams in charge of implementing clients. I settled for HTML forms, which are less powerful but easier to use.
      To get back to URI templates, now that I can provide tooling to some of the client developers, they could become a worthwhile addition.

      Putting aside the problem of dynamically communicating allowable values for expansion (let's progress one step at a time), I like your idea of <a rel="circle" hreft="/circle/radius;{radius}" />. As the hreft attribute isn't standard XHTML we would have to get it from our own namespace. This would give: <a rel="circle" my:hreft="/circle/radius;{radius}" />

      However it looks like it breaks the HTML 5 specification which states: "The target, rel, media, hreflang, and type attributes must be omitted if the href attribute is not present.

      We could mint a new rel attribute in our own namespace, which would give: <a my:rel="circle" my:hreft="/circle/radius;{radius}" />

      At that point however, I wonder if using <a> still makes much sense. What do you think?
      An alternative is to create a new element. If we name it "link", an XHTML representation containing this element would look like:

      <html xmlns="http://www.w3.org/1999/xhtml" xmlns:my="http://www.example.com/my">
      <my:link rel="circle" hreft="/circle/radius;{radius}" />

      What is your take on this? Can we do better?


      --- In rest-discuss@yahoogroups.com, Mike Kelly <mike@...> wrote:
      > On Wed, Nov 9, 2011 at 7:40 PM, Eric J. Bowman <eric@...> wrote:
      > >
      > > Mike Kelly wrote:
      > > >
      > > > There's already an adequate solution to that problem - you can define
      > > > the inputs up-front against the link relation in question.
      > > >
      > >
      > > I don't see invalid markup as an adequate solution -- @href takes a
      > > URI, not a template; section 1.4 of the URI-template draft states that
      > > URI templates aren't URIs.  Instead of having to parse @href before
      > > determining how to parse @href (is it a URI or a template), it makes
      > > sense to follow the logic in the URI-template draft and provide new
      > > attributes to match a new parsing model (or elements, in the case of
      > > XForms elements which take URIs as content).
      > >
      > > >
      > > > e.g. the link relation 'circle' has an href containing a URI template
      > > > which accepts the variable 'radius'
      > > >
      > > > which tells you what you need to know to build an automated client
      > > > which follows this link:
      > > >
      > > > <a rel="circle" href="/circle/radius;{radius}" />
      > > >
      > >
      > > How?  Does @href take on a different syntax due to the definition of
      > > rel='circle'?  Where is *that* in the media type definition for XHTML?
      > >
      > You're focusing on a side issue. Let's change it to this for now:
      > <a rel="circle" hreft="/circle/radius;{radius}" />
      > Is that (and the description of the rel circle) not an adequate
      > solution to the "real problem" you mentioned before?
      > Cheers,
      > Mike
    • Show all 19 messages in this topic