Re: Request feedback on fragment identifiers

Myriam,

Please review the earlier discussion of "temporal URI fragments"
which IIRC concluded that a name-value-pair-[list | bag] structure
such as is provided by the ?search-part syntax is a better fit to the
application than fragment syntax. At least where the application is
time slices of media streams [temporally distributed media objects].
I am not sure if the MPEG objects you are dealing with are internally
polychronic but I would tend to think that most of the applications
for subsetting or indexing into MPEG objects would be covered by
time-sliced tails and segments.

http://www.w3.org/Search/Mail/Public/search?keywords=URI+fragment+temporal&hdr-1-name=subject&hdr-1-query=&index-grp=Public__FULL&index-type=t&type-index=uri


While that reference will ultimately lead you to Silvia Pfeiffer
<Silvia.Pfeiffer@csiro.au> let me suggest up front that you might
want to discuss your project with her.

Al

If you find you want more complex selection patterns, write back
and we can talk other options.

At 2:55 PM +0900 7/9/04, Martin Duerst wrote:
>At 09:46 04/07/09 +1000, Myriam Amielh wrote:
>
>>Larry Masinter wrote:
>
>>>I'm not sure how the PDF fragment identifier syntax or the
>>>XML fragment identifier syntax have much to do with
>>>MPEG-21 fragment identifiers.... For application/pdf, there's
>>>one MIME type with one syntax. For XML resources, there
>>>are two MIME types (application/xml, text/xml), and then
>>>a recommendation for what future MIME types might do.
>>>
>>>I don't like the idea of having a sort-of-recommendation where
>>>multiple interpretations might apply.
>I wouldn't like that either. On the other hand, it makes sense
>to have fragment identifier syntax that may apply across media
>types if these types are similar enough to expect that the same
>contents might be served in these different media types.
>
>>>Without reviewing the MPEG-21 proposed scheme, I don't know
>>>whether to be concerned about verbosity, compatibility with
>>>fragment syntax, or compatibility with other addressing mechanisms
>>>(e.g., SMIL).
>>>
>>Well, I could send you the spec if you wish, just let me know...
>
>A summary of the actual proposal would be better, I guess.
>
>Regards,    Martin.

Received on Friday, 9 July 2004 16:13:02 UTC