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

4435Re: Re-using information fields for queries in REST

Expand Messages
  • thompsonbry
    Jun 3, 2004
      Dave,

      I searched on this a bit, but I could not find the gospel according
      to the TAG. However, it is my rememberance that URIs no longer have
      practical length limits and that people should not design interfaces
      as if they did.

      So, why not just serialize the XML using the XML syntax in, e.g.,
      UTF-8, and then escape any characters that need to be escaped for
      the URI encoding?

      I mean, we can probably do better than this, e.g., with a dictionary
      of namespace URIs, element names and attribute names that would yield
      a more compact representation of the XML instance data (all of which
      reminds me of binary XML), but why bother? Is't it good enough to do
      this in the simplest manner possible so that we can move forward?

      -bryan

      --- In rest-discuss@yahoogroups.com, "David Orchard" <orchard@p...>
      wrote:
      > I think one of the hardest parts of coming up with a "uriencoded-
      xml" format is dealing with those pesky QNames. I wrote a while ago
      about this
      http://www.pacificspirit.com/blog/2004/04/29/binding_qnames_to_uris.
      >
      > I've almost gotten to the point of thinking that it's just simply
      to awful to binding lexical QNames or NS decls to URIs for binding
      potentially many qnames to URIs. The approach of specifying that the
      ns decl is part of the "algorithm" allows for I think a pretty common
      case, the authority creating the resources can specify the ns name
      decls ahead of time. In this case, the creator of the Author
      resources not surprisingly owns the Author namespace names. A prefix
      is not required for the default namespace, and a prefix is required
      for using ns decls outside the default ns.
      >
      > There is a big downside in that the xml fragments are no-longer
      self-describing as they are missing their ns decls in-line. If
      somebody changes the namespace name but not the ns prefix, things
      could get pretty hairy. And distributed extensibility wouldn't be
      supported as a client that knew about a davens:extension that was
      unknown to the service wouldn't be able to send the extension they
      know about but wasn't in the algorithm. I suppose it could be
      possible to say that extensions can be sent in ugly lexical form as
      that is the "hard but possible" case in the "make simple things
      simple and hard things possible" algorithm.
      >
      > In retrospect, I'm becoming convinced that marrying XML sans
      namespace tree structures to the URI tree and query structure works
      fine, but marrying XML namespaced tree structures to URIs has been
      almost useless by the decision to make ns names absolute URIs. In
      order to map some kind of xml to URIs, we have to adopt some kind of
      constraints, like "ns decls are implicit", to make it usable. One
      thing I am curious about is whether people see much need for mapping
      mixed ns xml into URIs, or if most of the scenarios involved single
      ns..
      >
      > Cheers,
      > Dave
      >
      > -----Original Message-----
      > From: thompsonbry [mailto:thompsonbry@s...]
      > Sent: Wednesday, June 02, 2004 4:51 AM
      > To: rest-discuss@yahoogroups.com
      > Subject: [rest-discuss] Re: Re-using information fields for queries
      in REST
      >
      >
      > This sounds very relevant to how XForms could use GET.
      >
      > I am assuming that we want the stronger constraint of
      > bookmarkability, right? Not just caching?
      >
      > So that we are not talking about GET with a request body (which
      could
      > perhaps be made cachable, e.g., using "Vary") but a means of
      mapping
      > an XML document (which could be just a property set for flat vs
      > hierarchical addressing) into a URI.
      >
      > E.g., a "application/iriencoded-xml" MIME type.
      >
      > -bryan
      >
      > --- In rest-discuss@yahoogroups.com, "David Orchard" <orchard@p...>
      > wrote:
      > > I've been looking at how map an xml tree into the path and same
      > depth
      > > params into the forms, ala
      > >
      >
      <Music><Artist><Name>ThieveryCorp</Name><Rating>5</Rating></Artist></M
      > us
      > > ic>
      > >
      > > gets mapped into something like GET /Music/Artist?
      Name=ThieveryCorp
      > and
      > > GET /Music/Artist/Rating?Name=ThieveryCorp
      > >
      > > Mixed ns are a pain, but if you adopt the convention that the ns
      > decls
      > > are somehow in the algorithm, then it gets a little bit more
      > managable.
      > >
      > > Cheers,
      > > Dave
      > >
      > > > -----Original Message-----
      > > > From: Mark Baker [mailto:distobj@a...]
      > > > Sent: Tuesday, June 01, 2004 8:38 PM
      > > > To: David Orchard
      > > > Cc: rest-discuss@yahoogroups.com
      > > > Subject: Re: [rest-discuss] Re-using information fields for
      > queries in
      > > > REST
      > > >
      > > >
      > > > On Tue, Jun 01, 2004 at 05:47:54PM -0700, David Orchard wrote:
      > > > > Gotcha on the use of hierarchy rather than flat where
      > appropriate.
      > > > >
      > > > > > -----Original Message-----
      > > > > > From: Roy T. Fielding [mailto:fielding@g...]
      > > > >
      > > > > <snip/>
      > > > > > Anyway, we are talking about resource discovery over
      arbitrary
      > > > > > data categories, and hence non-hierarchical in nature.
      There
      > is
      > > > > > nothing wrong with telling the client how it can form URI's,
      > > > > > assuming that such a function doesn't change much over time.
      > > > > > Again, for cache reasons, I prefer methods of telling the
      > client
      > > > > > to use the template
      > > > > >
      > > > > > http://example.com/quotes/${exchange}/${symbol}
      > > > > >
      > > > > > rather than the template
      > > > > >
      > > > > > http://example.com/quotes?market=${exchange}
      > &symbol=${symbol}
      > > > > >
      > > > > > There is nothing stopping WSDL-like technology from defining
      > > > > > both of these mechanisms.
      > > > > >
      > > > > > ....Roy
      > > > > >
      > > > >
      > > > > Hey, now there's an idea. Maybe even official WSDL
      > technology...
      > > >
      > > > *groan* Ok, sure, *now* you support my "make WSDL more form-
      like"
      > > > suggestions. 8-)
      > > >
      > > > The new HTTP binding goes further in this direction, but still
      > falls
      > > > short largely because it bumps up against the *very* different
      > demands
      > > > of a forms language compared with an interface description
      > language.
      > > >
      > > > I'd personally prefer to start over with a forms language,
      which
      > is
      > > > why I created RDF Forms; http://www.markbaker.ca/2003/05/RDF-
      > Forms/ .
      > > > But it has a bit of legacy in its support of www-form-urlencoded
      > > > serializations for POST bodies and URIs largely because that's
      > what
      > > > server APIs easily support and it's what I used at work. But
      I'd
      > love
      > > > to get a more general generative naming language in there that
      > could
      > > > support hierarchy as Roy describes.
      > > >
      > > > Mark.
      > > > --
      > > > Mark Baker. Ottawa, Ontario, CANADA.
      > http://www.markbaker.ca
      >
      >
      >
      > Yahoo! Groups Sponsor
      >
      > ADVERTISEMENT
      >
      <http://rd.yahoo.com/SIG=129ga231f/M=295196.4901138.6071305.3001176/D=
      groups/S=1705701014:HM/EXP=1086263534/A=2128215/R=0/SIG=10se96mf6/*htt
      p://companion.yahoo.com> click here
      > <http://us.adserver.yahoo.com/l?
      M=295196.4901138.6071305.3001176/D=groups/S=:HM/A=2128215/rand=2945531
      86>
      >
      >
      > _____
      >
      > Yahoo! Groups Links
      >
      >
      > * To visit your group on the web, go to:
      > http://groups.yahoo.com/group/rest-discuss/
      >
      >
      > * To unsubscribe from this group, send an email to:
      > rest-discuss-unsubscribe@yahoogroups.com <mailto:rest-discuss-
      unsubscribe@yahoogroups.com?subject=Unsubscribe>
      >
      >
      > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
      Service <http://docs.yahoo.com/info/terms/> .
    • Show all 23 messages in this topic