(This email details important changes to the Requirements document and
to the Packaging spec in regards to the widget URI scheme. If this
affects you, then please read it and comment.)
Hi Cyril,
On Sat, Oct 11, 2008 at 9:36 AM, Cyril Concolato
<cyril.concolato@enst.fr> wrote:
> Hi,
>
> It seems to me that Requirement 6 should be split into two requirements:
Looking at it again, I actually see three requirements:
1. An addressing scheme (which is not necessarily a URI scheme, i.e.,
relative and absolute paths) to address resources in the package from
the config doc and from HTML docs, CSS docs, etc, inside the widget
package.
2. The addressing scheme becomes a URI scheme at runtime (for the sake
of the DOM).
2.1. But the URI scheme must not expose the underlying operating
system (for privacy and security) OR the widget engine must prevent
authors from using the URI scheme to access the underlying operating
system (even if it's possible, as is the case with file://).
3. The URI scheme (or some other means/model) MAY be used to address
other widgets (for cross widget communication). This requirement is
actually covered by R32, so it's not necessary to make this explicitly
part of the URI scheme. R32 reads:
"A conforming specification MAY specify a model or API to allow
multiple instantiated widgets to securely communicate with each other.
A conforming specification attempting to address cross-widget
communication SHOULD provide a way for users to be aware of widget
dependencies and to introduce widgets to each other ("pairing" and
"unparing")."
> A. "A conforming specification MUST specify or recommend an addressing
> scheme to address the individual resources within the widget resource at
> runtime."
You are right in that the requirement needs to be rewritten and split.
Hopefully this new text makes things more clear and simple and
attempts to capture 1. above:
"A conforming specification MUST recommend a hierarchical addressing
scheme that can be used to address the individual resources within a
widget resource from within a configuration document. In addition, the
hierarchical addressing scheme MUST be interoperable with resources
that might also need to address resources within the widget resource
(e.g., HTML documents, CSS documents, JavaScript documents, etc.). The
addressing scheme SHOULD be one that Web authors would feel
comfortable using or to which they are already accustomed.
Rationale:
To make it easy for authors to address resources from the
configuration document or other relevant resources within the widget
package. For example, addressing a custom icon within a widget package
from the configuration document (e.g. <icon src="icons/cat.ico'>). Or,
for example, addressing an image within a widget package from within
the start file (e.g. <img src="/backgrounds/sky.png'>). "
My mentioning of the "runtime" in the original requirement was
screwing everything up. What happens at "runtime" constitutes a
separate requirement. What it should have said is that the addressing
scheme needs to be resolved to some hierarchical URI scheme
(requirement 2. above). So, at runtime, icon.src from the example
above, would become
"someScheme:someAthority/path/to/icons/widget.png".
*** This effectively means that there will be no URI scheme defined in
the Packaging Spec (but instead moved to the API spec, so the
"discussion" continues;)). The text for the new requirement is at the
end of this email. ***
> B. "A conforming specification MUST specify or recommend an addressing
> scheme to address individual widget instances."
>
So yes, this is an independent requirement.
> For requirement A, I think that, given that the WG specifies a Packaging
> Format for Widget, it could define as well a Fragment Identifiers syntax for
> this package. This would have the advantage of separating/hiding the
> protocol used to retrieved the widget and therefore address the problem of
> "The addressing scheme MUST NOT expose the underlying file system (if any)".
> I think authors are also used to that mechanism and therefore would satisfy
> "The addressing scheme SHOULD be one that web authors would feel comfortable
> using or to which they are already accustomed."
>
Interesting, can you illustrate what this Fragment Identifiers syntax
would look like? And will it be easier to use than relative paths and
absolute paths?
> For requirement B, correct me if I'm wrong, but since the exact identifier
> of a widget instance can only be known at runtime, I don't see how an author
> can determine it declaratively as a URL before instantiation.
You are right. I screwed up the way the requirement is written. Like
you said, they are separate and quite independent requirements.
>So, the URL to
> the widget instance has to be created at runtime as well. Therefore, I
> imagine that there could be an API to do the following: querying the
> available widget instances, then requesting a URL (internal to the User
> Agent) to a particular widget instance and finally creating the final URL
> using the previous URL and appending a proper fragment identifier.
>
> Therefore it seems to me that a new URI scheme is not necessary. Where is my
> reasoning wrong?
URI attributes in DOM nodes need to be expanded to something. And,
Like I said to Mark, there is a risk that, without proper guidance,
implementers will mint their own URI schemes which, without proper
consideration, could lead to privacy or security problems (see my
previous email). If vendors are allowed to get too fancy minting their
own schemes, then that may cause interop issues in the future (V2.0).
Taking your suggestions and Marks suggestions, I've created requirement 36:
"R36. Resolve Addressing Scheme to URI Scheme
A conforming specification MUST recommend that, at runtime, the
addressing scheme used by a resource that addresses another resource
within a widget package be resolved to some hierarchical URI scheme. A
conforming specification SHOULD recommend an appropriate URI scheme:
That is, a URI scheme that does not expose the underlying file system
(if any) to the instantiated widget. In addition, an instantiated
widget MUST NOT be able to address resources outside the widget
resource via the URI scheme (even if URI scheme allows it).The URI
scheme MUST pertain to individual widget instances, but it MAY
potentially allow widgets to address each other (for instance, when
used in conjunction with cross-widget communication).
Rationale:
To allow resources to be resolved and normalized within DOM
attributes. For example, addressing a resource via an IRI reference
(e.g. <img src="images/bg.png'/> where the src attribute resolves to
something akin to "widget://myWidget/images/bg.png")."
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au