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

Re: [rest-discuss] Re: Using URI templates in XHTML

Expand Messages
  • Marc Portier
    ... ah ok, since you mentioned XHTML I just assumed browser-client and expanded further to assume javascript, sorry for that ... Well, that surely *is* an
    Message 1 of 19 , Nov 13, 2011
    • 0 Attachment
      On 10-11-11 15:40, Philippe Mougin wrote:
      > Marc, thanks for answering.
      >
      > > > I'm now in possession of a shinny new URI-template library
      > (implementing
      > > > http://tools.ietf.org/html/draft-gregorio-uritemplate-07) that I
      > plan to
      > >
      > > care to share which one?
      >
      > It's a Java library developed by a colleague. It isn't publicly
      > available (yet).
      >
      > > Below I assume you think about in-browser (js) code that will be
      > > expanding the templates, right?
      >
      > In my context, this isn't necessarily in-browser code, or js code (more
      > likely Java, C# or Perl code). But yes, I 'm talking about client side
      > expansion of URI templates communicated by the server.
      >

      ah ok, since you mentioned XHTML I just assumed browser-client and
      expanded further to assume javascript, sorry for that

      > > Anyway, in terms of HTML such I think the lists of contexts could be
      > > provided by any repeating thing like ul/li, table/tr, p
      >
      > 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?

      > certainly missing some pieces here!
      >

      Not sure, maybe I'm missing the pieces, but here is my line of thinking:
      if you think about sending uri-templates to the client, then I assume
      you want it doing the expansions, and thus, that client will need to
      have a way to access, derive, produce the contexts for that...

      So really, in my mind relating this issue to XHTML (as per your subject)
      really opens up two interesting issues:

      [1] a way to send the uri-templates (link/ref, or the suggested hreft,
      srct variants) ... or ...

      [2] and a way to send the contexts

      regards,
      -marc=

      > Philippe
      >
      >
    • 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 2 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 3 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 4 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.