Widget scheme

MURATA Makoto (FAMILY Given) eb2m-mrt at asahi-net.or.jp
Sun Nov 15 23:22:42 CET 2009


Rick,

I think that Roy assumed that 1) a packaged is created from a collection
of resources, each of which is refernced by an URI, 2) references to
parts occur in other parts only, and 3) such references are original URIs. 
He is saying that these references can be reinterpeted thanks to the
(part name, uri) list so that parts in the packages are accessed.  I do not think that
these asssumptions apply to OPC, where 1) parts do not have obvious URIs
when they were created, and 2) parts should be accessbile from
everywhere.  (I don't think that Roy's scenario requires server-side
processing, though.  Moreover, his scenariohas worked for the past 10
years for MTHML.)

However, his critisms on the pack scheme appear to hold water.
> What is unusual is the
> suggested solution of a "pack" URI that inverts the entire addressing
> space to satisfy a single media type. That simply isn't done because it
> is contrary to the way the Web has been designed to work.
> 
>    http://www.w3.org/TR/webarch/#URI-scheme
>    http://www.w3.org/TR/webarch/#orthogonal-specs
>    http://www.w3.org/2001/tag/doc/mime-respect.html#external
>    http://www.w3.org/2001/tag/doc/metaDataInURI-31

What you summarized appear to be similar to Mark's suggestion, skeched
in http://www.ietf.org/mail-archive/web/uri-review/current/msg00514.html 
and expanded by his later mails in the thread.   Svante mentioned something 
similar to me.  One limitation is that this works only the http scheme
and that parts are extracted only on the HTTP server side.

I think that we have to clarify requirements first.  Who extracts parts
from packages?  On the server side or the client side?  Svante tried 
in his first mail to public-pkg-uri-scheme at w3.org. 

http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/2008Dec/0001.html 

I am very much interested in the upcoming discussions about the widget 
scheme in the uri-review at ietf.org mailing list.

Cheers,
Makoto


More information about the sc34wg4 mailing list