RE: [BULK] Re: Is an XForm an application for, or a representation of an instance data?

Eric Bowman wrote:

> Well, yeah, it's interesting to debate this point, but I'm missing the practicality bit...  ;-)

There is a practical point and it revolves around the use of media-type in the Accept header to differentiate between the purpose/functionality of a representation. Sorry if I was vague about that.


Eric Bowman wrote:

>> 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.

In the example I was talking about, a requested media-type of 'text/html', for the desired instance data, would return an XForm that referenced, using 'application/xml', the desired instance data. 

For myself, I see an XForm as an 'web' application, or at least a definition there-of, in its own right and consequently a resource in its own right; one that provides a means by which the user can retrieve, edit and submit instance data resources. As a result, I see requesting an XForm 'as a representation' of the resource you wish to edit as a less common use-case for XForms and is problematic when faced with potentially conflicting functionality for the same media-type. How do you then further differentiate between the XForms enable HTML representation and a 'vanilla' HTML representation.

The philosophical part is whether an XForm could be regarded as a representation of an instance data resource. Probably yes, but it doesn't sit right with me (but that could just be me). The practical part is how you effectively request representations that have different functionality but share the same 'base' media-type for the requested representation.



Regards

Philip


-----Original Message-----
From: Eric J. Bowman [mailto:eric@bisonsystems.net] 
Sent: Thursday, July 28, 2011 3:14 AM
To: Philip Fennell
Cc: www-forms@w3.org
Subject: [BULK] Re: Is an XForm an application for, or a representation of an instance data?
Importance: Low

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 Monday, 1 August 2011 06:19:55 UTC