- From: Eric J. Bowman <eric@bisonsystems.net>
- Date: Wed, 27 Jul 2011 20:14:05 -0600
- To: Philip Fennell <Philip.Fennell@marklogic.com>
- Cc: "www-forms@w3.org" <www-forms@w3.org>
Philip Fennell wrote: > > This is good philosophical stuff but with a practical edge to it: > Well, yeah, it's interesting to debate this point, but I'm missing the practicality bit... ;-) > > The implication is that if you use the same URI then the XForm must be > regarded as another representation of the resource pointed to by the > URI. > Yes, that, or protocol abuse on the origin server's part. You haven't given enough context about the conneg implementation to make that determination, though. The finer point here, is that each representation is also (arguing with me over whether 'is also' should be 'may also be' is a rest-discuss permathread) a resource in its own right; which is why it's a best practice to assign identifiers to all variants (excluding compression) using the Content-Location header -- helps keep it all straight, particularly for code developers/maintainers, even if no component in an HTTP transaction actually reads that header. Or the Location header, if you're redirecting... > > 1) If you embed an instance data document inside an XForm that > provides a view of the document's content, can the resulting XForms > document be thought of as a representation of the instance data? > I don't know what "the resulting XForms document" means; an XForm containing instance data is a representation of whatever resource's identifier was used to dereference it. What a user-agent does with a representation, i.e. process it into a user interface, does not occur at the protocol layer and thus has no bearing on protocol terminology. An XForms document which links to an instance, is still a representation of whatever resource's identifier was used to dereference it. In neither case is the XForms document a representation of the instance. > > 2) If the answer to the (1) is 'yes', then does that still hold true > when the instance document is no longer embedded, in-line, but is > included by URI reference instead? > A representation with CSS contained in <style>, is a representation of whatever resource's identifier was used to dereference it; externalizing the CSS using <link/> instead, does not change this. The external CSS is a resource in its own right, as it has its own URI; but it is not a representation of the resource whose representation has the <link/>... ...unless that <link/> is also rel='self'; it's easy to configure an httpd to negotiate between HTML and CSS variants of the same URI, but that's what I call protocol abuse rather than confirmation that the two variants are actually equivalent. But, what is meant by "equivalents" and does it apply equally to 200 responses vs. 301 redirection? Let's say I have a resource /foo and I want feed readers to get Atom, and browsers to get an XForms feed- reader app. I could use 200 responses, and make it work; but having built exactly such a system, I can vouch that it will save a lot of headaches to use 301 redirection because they're only "equivalent" *after* transclusion. Whereas text/html and application/xhtml+xml variants may be 100% equivalent, in which case use 200 responses. With plenty of grey area in-between, my point being, don't be afraid to mint URIs, particularly when REST is the goal. > > 3) If you're happy that the answers to (1) and (2) are 'yes'... > I continue under protest due to the imprecise terminology of the questions... :-) > > given that both the XML representation of the resource and the XForm > representation of the resource are nominally application/xml but the > later could be application/xhtml+xml, how would you use content > negotiation to differentiate between the two requests? > By wrapping the XML in Atom and giving it its own URI, and negotiating based on Atom preference; browsers will get some sort of cross-platform XForms solution because they won't prefer Atom. See [2], below... > > You have to take into account the fact that different XForms > implementations require different response content-types in order > that the form will be processed correctly and also you cannot > rule-out that a plain application/xhtml+xml (XHTML) representation > may also be required. > I was working on that very problem a few months back, this is WIP... [1] http://charger.bisonsystems.net/date.xht XSLTForms needs tweaking to work with this approach, which is best explained here because I don't think I got further than placeholder code/comments which only make sense to me: basically, an XForms case/ switch handles native XForms processors; otherwise a script fires which calls XSLTforms, which should abort if a native XForms processor exists. A bit clunky, but the approach should address the various cross-platform issues you mentioned cleanly. Input appreciated. > > The ability to request a representation of a resource that allows the > resource to be edited is an interesting one and I'm not sure it has > been covered in any great detail if at all. > It's at least as common as WebDAV. ;-) Also, Netscape Communicator had an HTML editor that worked this way, so it's nothing new. > > Is the editing application a resource in its own right or a > representation of the resource. > Could be both. > > It's all rather relative and seems to revolve around whether you see > the user accessing the resource to edit it or they access an editing > application (the XForm) that retrieves the resource. > It's unambiguous to me, sorry if that bugs anyone. My (by no means complete) demo, which will eventually have an XForms interface (it exists, but isn't ready for prime-time), shows a system built around Atom which may be manipulated by Atom Protocol clients or HTML browsers: [2] http://charger.bisonsystems.net/conneg/ Just imagine the HTML is XForms (authenticated users will get XForms interfaces, the capabilities of which will vary by user role, what you see on the demo would go to un-authenticated users), and note that the XForms document will GET an Atom document as an instance, and PUT that Atom document back to its own URL; it is not necessary to use conneg- based chicanery to serve that Atom document and the XForms document from the same URL. In fact, doing it that way can be very limiting -- [2] has one XForms document for a huge number of XML documents; if each date request required a new XForms document to load it wouldn't be a static-page dynamic interface. Again, don't be afraid to mint more URIs. -Eric
Received on Thursday, 28 July 2011 02:14:37 UTC