W3C home > Mailing lists > Public > public-media-fragment@w3.org > October 2010

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 28 Oct 2010 09:59:39 +1100
Message-ID: <AANLkTimZ83Ssrxt67gBjhYuek9gpo_0u=_OJjTn_vxHX@mail.gmail.com>
To: Media Fragment <public-media-fragment@w3.org>
An interesting discussion happening on the uri mailing list and very
relevant to us...


---------- Forwarded message ----------
From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, Oct 28, 2010 at 9:49 AM
Subject: Re: is it possible to handle an XML/HTML elements attribute
via the URI?
To: "Cheney, Austin" <Austin.Cheney@travelocity.com>
Cc: Matthew Millar <mattmill30@hotmail.com>, "uri@w3.org" <uri@w3.org>

Hi Austin,

You are completely correct in that the spec as it stands right now
primarily considers the use of media fragments for HTTP URIs. However,
there has been work in the group to apply it to RTSP URIs and to FILE
URIs. It is much easier for those since byte range requests are a lot
easier to handle there. It is difficult to see whether there is a use
case to go beyond these protocols with media URIs.

Since according to RFC 3986 the specification of the meaning of
fragments is restricted to media types, that may be sufficient.

It would indeed be interesting to introduce a more generic structuring
of fragment specifications along the line of name-value pairs
concatenated through "&" , or in your example through ",". That wasn't
the aim of what the media fragment URI working group was set up for,
but their outcome can be a motivation to make this larger step here,
if we can.

Finally about your concern that media fragment URI is not compatible
with RFC 3987 - can you explain what part of the spec makes it
incompatible with RFC 3987 and how that compatibility may possibly be
achieved? I believe the working group may lack expertise in this area
and any input / suggestions would be very welcome.

Best Regards,

On Thu, Oct 28, 2010 at 9:13 AM, Cheney, Austin
<Austin.Cheney@travelocity.com> wrote:
> 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
> -----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 23:00:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:45 UTC