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

Re: Using URI templates in XHTML

Expand Messages
  • Philippe Mougin
    ... Yes, I need client side expansion, as I want to use URI templates to dynamically communicate how to build certain URIs. However, my clients are
    Message 1 of 19 , Nov 15, 2011
    • 0 Attachment
      > > Interesting. This resonates with the problem Eric wrote about:
      > > dynamically passing a declarative description of constraints on allowed
      > > values for expansion. In your example, you communicate a list of
      > > possible contexts for expansion. A context is a set of value for
      > > performing a given expansion. Do I understand correctly? If so, I'm not
      > > sure why you don't directly pass to the client a list of URI generated
      > > server-side by expanding the "templates" using the various contexts? I'm
      >
      > Well, that surely *is* an option as I mentioned myself, but if you go
      > this path, then you don't need to provide the client with uri-templates
      > nor contexts, and you don't need anything else then the xhtml we already
      > have...
      > So I just assumed you meant this, if not it seemed to make your question
      > void?

      Yes, I need client side expansion, as I want to use URI templates to dynamically communicate how to build certain URIs. However, my clients are purpose-built programs whose developers will be given some informations out of band. For example, I might communicate http://example.com/stockquote/{symbol} dynamically, associated with a given rel value for finding it in a representation, but specify in my service documentation (i.e., out of band) that it must be expanded using a variable named "symbol" whose value must be the stock symbol of the company you want a stock quote for.

      So my main question is what you labeled as "question [1]": what is the best way to embed such an URI template in XHTML.

      One viable option is creating a specific "link" element with a rel and hreft attribute, which would give:

      <html xmlns="http://www.w3.org/1999/xhtml" xmlns:my="http://example.com/my">
      <body>
      <my:link rel="http://example.com/rels/stockquote" hreft="http://example.com/stockquote/{symbol}" />
      </body>
      </html>

      Another idea I have is to use the existing xrd's link element, which has support for URI templates (xrd is specified at http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html).

      This would give:

      <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xrd="http://docs.oasis-open.org/ns/xri/xrd-1.0">
      <body>
      <xrd:link rel="http://example.com/rels/stockquote" template="http://example.com/stockquote/{symbol}" />
      </body>
      </html>

      I'd be grateful for any feedback on these as well as other ideas on how to best use URI templates as hypermedia controls in XHTML.

      Philippe
    • mike amundsen
      PM: the choice between adding a custom LINK element to XHTML or one based on XRD is not too interesting; i suspect they
      Message 2 of 19 , Nov 15, 2011
      • 0 Attachment
        PM:

        <puts-on-his-client-developer-hat>
        the choice between adding a custom LINK element to XHTML or one based
        on XRD is not too interesting; i suspect they would both need
        essentially the same development effort in order to recognize, parse,
        and process in representations.
        </puts-on-his-client-developer-hat>

        <puts-on-media-type-designer-hat>
        when implementing these "templates" (whether via HTML FORM, URI
        Template, or some other method), i include the possible "fields" that
        would appear in a template as documentation. this is totally
        out-of-band data, of course. and that data must be "incorporated" by
        server and client devs in some way. it's basically a dictionary of
        possible data points that both client and server need to keep in mind
        as possible values passed in transitions (templates) or steady-states
        (response representations). what/how implementors handle this is up to
        each case.
        </puts-on-media-type-designer-hat>

        hopefully that helps.

        MCA

        mca
        http://amundsen.com/blog/
        http://twitter.com@mamund
        http://mamund.com/foaf.rdf#me





        On Tue, Nov 15, 2011 at 09:31, Philippe Mougin <pmougin@...> wrote:
        >
        >
        >
        >
        >
        >> > Interesting. This resonates with the problem Eric wrote about:
        >> > dynamically passing a declarative description of constraints on allowed
        >> > values for expansion. In your example, you communicate a list of
        >> > possible contexts for expansion. A context is a set of value for
        >> > performing a given expansion. Do I understand correctly? If so, I'm not
        >> > sure why you don't directly pass to the client a list of URI generated
        >> > server-side by expanding the "templates" using the various contexts? I'm
        >>
        >> Well, that surely *is* an option as I mentioned myself, but if you go
        >> this path, then you don't need to provide the client with uri-templates
        >> nor contexts, and you don't need anything else then the xhtml we already
        >> have...
        >> So I just assumed you meant this, if not it seemed to make your question
        >> void?
        >
        > Yes, I need client side expansion, as I want to use URI templates to dynamically communicate how to build certain URIs. However, my clients are purpose-built programs whose developers will be given some informations out of band. For example, I might communicate http://example.com/stockquote/{symbol} dynamically, associated with a given rel value for finding it in a representation, but specify in my service documentation (i.e., out of band) that it must be expanded using a variable named "symbol" whose value must be the stock symbol of the company you want a stock quote for.
        >
        > So my main question is what you labeled as "question [1]": what is the best way to embed such an URI template in XHTML.
        >
        > One viable option is  creating a specific "link" element with a rel and hreft attribute, which would give:
        >
        > <html xmlns="http://www.w3.org/1999/xhtml" xmlns:my="http://example.com/my">
        >    <body>
        >        <my:link rel="http://example.com/rels/stockquote" hreft="http://example.com/stockquote/{symbol}" />
        >    </body>
        > </html>
        >
        > Another idea I have is to use the existing xrd's link element, which has support for URI templates (xrd is specified at http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html).
        >
        > This would give:
        >
        > <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xrd="http://docs.oasis-open.org/ns/xri/xrd-1.0">
        >    <body>
        >        <xrd:link rel="http://example.com/rels/stockquote" template="http://example.com/stockquote/{symbol}" />
        >    </body>
        > </html>
        >
        > I'd be grateful for any feedback on these as well as other ideas on how to best use URI templates as hypermedia controls in XHTML.
        >
        > Philippe
        >
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
      • Eric J. Bowman
        ... Surely this information can be written down and linked to in-band? Hard-coded clients aren t such a bad thing if, at least, the shared understandings are
        Message 3 of 19 , Nov 15, 2011
        • 0 Attachment
          "Philippe Mougin" wrote:
          >
          > Yes, I need client side expansion, as I want to use URI templates to
          > dynamically communicate how to build certain URIs. However, my
          > clients are purpose-built programs whose developers will be given
          > some informations out of band.
          >

          Surely this information can be written down and linked to in-band?
          Hard-coded clients aren't such a bad thing if, at least, the shared
          understandings are linked to (as opposed to baked-in / out-of-band).

          >
          > So my main question is what you labeled as "question [1]": what is
          > the best way to embed such an URI template in XHTML.
          >

          OK, I think I see what you're after, this is rough but ought to make
          everybody happy (except that it's bad HTML5), and is what is meant by a
          self-documenting API...

          http://charger.bisonsystems.net/stooges.txt

          ...because the code is simpler than prosaic documentation, even though
          the URIs are hypothetical and the XSLT, nonexistent. Obviously, either
          XSLT or Javascript can be used to generate a UI from that information,
          with the option of output in XHTML (whole pages) or JSON (snippets).

          Using URI templates as an outright replacement for links and forms in
          XHTML, decouples both the choice of forms language and the method of
          URI generation. The resulting XHTML (relying on pre-HTML5 <object>
          syntax in more ways than one) is svelte, and reduces the need to look
          deeper into the code to figure out how to build URLs in a way that's
          uniform across approaches / coding-language choices.

          RDFa is used to declare that the in-scope (domain-specific) vocabulary
          represents nicknames of people, the terms and meanings of the out-of-
          scope (shared understanding) vocabulary are left to the externally-
          linked document. The link is what counts, but @valuetype gives us the
          semantics needed to do name-value expansion for a template passed in
          @data, a nice repurposing of obsolete code IMNSHO.

          No, you don't have to use the XSLT (or JS), or use the service in a
          browser, but that option not only makes it easier for others to learn
          your service (particularly if your markup is valid and accessible), it
          also provides the opportunity to delimit which options from the shared
          vocabulary aren't supported locally (graying out a list item); the
          benefit of XSLT/XForms over JS here is one of declarative code vs. code-
          on-demand (visibility).

          I basically just had my aha moment for URI templates in XHTML, as it
          moves UI design choices (like forms language) to another layer.
          Interesting!

          -Eric
        Your message has been successfully submitted and would be delivered to recipients shortly.