RE: is it possible to handle an XML/HTML elements attribute via the URI?

The media-frags draft looks rather scary.  In the context of the web it is a great idea and incredibly useful for the media propositions in HTML5.  URI, however, is not a property of the web.  URI is protocol agnostic and intentionally so.  This draft's language appears to be an extension to URI and not an extension to HTTP URI scheme.  In order for that specification to not be a horrendous technology collision outside of HTTP it must limit do one of two things:

1) Extend URI agnostically
2) Limit itself to an extension of HTTP URI scheme

The second option would be the safest path as it represents a more narrow testing and compatibility objective.  The problems, though, not addressed in the draft is that there is no documented specification for the HTTP URI scheme specifically and secondly this document does not address its relation to HTTP versus HTTP's relationship to URI.  Understanding relationship distinctions in this space is important for intentionally specifying this document's role concurrent to prior existing technology so as to establish degrees of separation.

In example how does the draft address document processing using the file URI scheme for local media processing or such processing an undefined presumption?  Additionally, would such an extension not be equally beneficial for selectively address media specifics via executing a query against data repositories using any number of proprietary URI schemes?  Furthermore consider the difference between a mailto URI scheme and a SMTP URI scheme.  I have thought out the SMTP scheme, but not written it.  A mailto scheme is a functional extension for addressing email from documents intended for delivery over HTTP, but can be used equally outside HTTP.  The intention of the mailto scheme is for authoring a message with intention for transfer over SMTP, but it is not a method of addressability as is the case for most other URI schemes.  If a SMTP URI scheme were written to allow addressing of data transferred using the SMTP protocol it would likely have a function similar to HTTP.  This would be beneficial since such a scheme may provided a method to universally point to content in email repositories regardless of proximity to such repositories.  That said, if the scheme is written as a pointer to content or documents residing in email repositories it would be functionally similar to the HTTP URI scheme and equally benefit from any extensions to that scheme.

Consider this example:
smtp://austin.cheney@travelocity.com/inbox/uri-request/2009/april/subject="draft action pending"#section[3],type="video",query="cheney",action="resolve"

In that example I could point to a location in a specific email repository that references a specific email and document section requesting a query of potential media assets stored there.  Additionally, I could submit an action to occur that changes the response from the distant location if an ok transmission code is returned.  In this context it is import to understand that URI schemes define addressing syntax methods in conformance to the URI specification and do not necessarily specify a mode of transmission, as in an application layer protocol, by which that addressing communicates to the distant end.  In this sense a proposed SMTP URI scheme could use HTTP to engage the transmission, there by having a RFC 2616 data header instead of a RFC 5321 data header, but it is not the same as HTTP since it would propose a definition for syntax that may be entirely incompatible with HTTP.

It is entirely essential that future compatibility issues be addressed because even if something like a SMTP URI scheme does not yet exist the URI definition does currently exist and any scheme dependent extension of URI that is not defined with such a limitation would violate the intent of RFC 3896..

Last, but not least, if that draft is not HTTP dependent is there any intention for the future compatibility with RFC 3897?  HTTP is not compatible with RFC 3987 and the intention to establish that compatibility is not clear, and so it is presumed that HTTP dependent artifacts have no intention of achieving RFC 3987 compatibility.

Thanks,

Austin Cheney, Travelocity User Experience
CISSP TS/SCI


-----Original Message-----
From: uri-request@w3.org [mailto:uri-request@w3.org] On Behalf Of Silvia Pfeiffer
Sent: Wednesday, October 27, 2010 4:13 PM
To: Matthew Millar
Cc: uri@w3.org
Subject: Re: is it possible to handle an XML/HTML elements attribute via the URI?

On Thu, Oct 28, 2010 at 3:21 AM, Matthew Millar <mattmill30@hotmail.com> wrote:
> Hi,
>
> I'm wondering whether its possible to handle a page element, via the URI?
>
> I'd like to handle an elements attribute, based on its ID.
>
> Like an expansion of the #ID URI feature.
>
> I'm hoping for something like:
>
> http://domain/page.html#ID[dir]="ltr"
>
> In the example above, i would want to add the "dir" attribute, with a value
> of "ltr", to the element whose id is "ID"
>
> If its not currently possible, could it be considered for a future standard,
> or an extension to the current URI standard.
>
> Thanks,
>
> Matthew Millar
>


I'm thinking about a similar thing for media fragment URIs[1] where it
would be nice to be able to say in the URI which video on the page
should be displayed from what time offset or what chapter. Something
like:

http://example.com/page.html#video[0]&t=50
http://example.com/page.html#video[1]&id=chapter-3

XPointer[2] allows for such addressing as you are proposing on xml
documents, e.g. http://domain/page.html#xpointer(id('xyz')) . However,
it doesn't provide means to change the value of attributes - and I am
not sure that should be the aim of standard URIs. It would be
something that you'd need to do in your application, so use a query
parameter instead, e.g. http://domain/page.html?ID[dir]="ltr", and
process it in your server app.

Cheers,
Silvia.


[1] http://www.w3.org/TR/media-frags/
[2] http://www.w3.org/TR/xptr-framework/

Received on Wednesday, 27 October 2010 22:14:56 UTC