Marcos, Mark, all,
I am picking up the discussion where Cyril left it some months ago. I
have read this thread, the Oct 08 one, the proposed URI scheme spec,
even skimmed through the wam minutes. I still am leaning towards Mark's
position. It seems to me that the URI scheme is not needed, or if
needed, the reasons have not yet been "shown".
I am trying to reformulate the situation:
0- the author needs a way to point to resources within the widget package
1- the "URI scheme will never be used by the author" (written by
Marcos), the author will use relative URIs for resources within the widget.
2- the browser will have to resolve the relative URI to an absolute URI
because of the DOM spec, hence a possible vulnerability by divulging
private information (e.g. actual name of current user in file: URI
example of Apple Dashboard widgets) to scripts running in the widget.
3- Marcos seems to be deducing from 2- that a URI scheme must be defined
for mandatory internal use in all widget UAs to guarantee that this
vulnerability does not exist.
3- does not follow logically from 2-.
"Mandating the implementation in the widget UA of a URI resolution that
does not divulge private information to the widget scripts" is
sufficient to ensure that the vulnerability mentioned in 2- does not
happen. The proposed URI scheme could be suggested as an option, but not
more.
My understanding is that 3- mandates a particular URI scheme which will
never be used by the author and will never be exchanged between two
implementations.
My past standardization experience is that things which "will never be
used by the author and will never be exchanged between two
implementations" should not be standardized at all. Are there other
predicates for the need for standardisation ?
Marcos mentions the widget V2 spec and extensibility as one reason for
adopting the proposed URI scheme. I would like to understand how V2 and
extensibility could make the URI scheme either seen by the author or
exchanged between implementations, or make its absence otherwise imperil
implementations.
Thanks.
Best regards
JC
--
JC Dufourd
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France
