W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

[widgets] FYI - Opera's feedback to BONDI

From: Marcos Caceres <marcosc@opera.com>
Date: Fri, 20 Mar 2009 16:30:07 +0100
Message-ID: <b21a10670903200830h7b3c86caq22c2e1a2c32eb1fe@mail.gmail.com>
To: WebApps WG <public-webapps@w3.org>
FYI, the following is some of the feedback Opera has sent to BONDI re:
their Architecture document [1]. It should become available publicly
at [2] at some point, where other feedback from Opera is available.

If you have not already done so, I strongly encourage everyone to read
and send feedback to BONDI about this important public document [1].
It's critical to the success (or demise!) of widgets. To send
feedback, go to [2] (or I guess you can email David Rogers directly,
david.rogers@omtp.org).

[1] http://bondi.omtp.org/Documents/CR10/BONDI_Architecture_Security_Task_CR10.pdf
[2] http://bondi.omtp.org/Lists/BONDI 10 CR  Feedback/AllItems.aspx

===
After our internal review of the specification, Opera finding's
reflect and strongly support the findings of Ikivo's review of both
the APIs and Architecture documents and would like to see all issues
thus far raised addressed before these specs can be considered "1.0".
In particular, we strongly support Ikivo's recommendation that the
BONDI work harder to complete the foundational W3C specifications and
have two interoperable implementations be available before BONDI can
be considered 1.0. This aligns with the W3C's model for
standardization of specifications (to not have at least two proofs of
concept seems dangerous given the importance of the BONDI and W3C work
to the industry).

In addition, we seek clarification and alignment with regards to the
extensions to the W3C specifications (again, building on the findings
of Ikovo's review of the Architecture spec). We also see the
mobile-centric view of many parts of these specifications as limiting
the overall applicability of the BONDI specifications; we would like
to see a greater generalization of the whole architecture that makes
the platform mobile agnostic. As already stated, we are strongly
against forking the W3C specifications in the manner currently being
specified by the architecture document: that is, the addition of new
elements and processing rules that, from our point of view, add little
value. If any elements are strongly required by BONDI, they should be
brought over to the W3C's Web Apps WG for standardization as part of
their Last Call phase. It is Opera's position that all elements in the
<bondi> namespace, including the <bondi> element, should be dropped.

Comments:
The use and capitalization of RFC2119 terms (MUST, MAY, SHOULD) is
globally inconstant. It is confusing to the reader when a, for
instance, a "may" means a "MAY". To avoid confusion, RFC2119 terms
that are not intended for conformance need to be avoided/changed.
There are too many instances of such inconsistencies throughout the
specification for me to list here.

Another serious problem arises from the inconsistent use of RFC2119
terms: it is really unclear what an implementer needs to do to conform
- the overall conformance model needs a serious look at.

AS-0020 - this requirement is unclear. Could you expand on it?

AS-0180 - says that a widget SHALL be treated as invalid, but does not
define what that means in the context of BONDI (please reference the
W3C P&C spec, which uses the term "invalid widget" and how one should
be treated. http://dev.w3.org/2006/waf/widgets/#invalid-widgets)

AS-0200 - forks parser behavior of the W3C's P&C spec. This should be avoided.

AS-0230 - version system is confusing and, as Ikivo's review stated, is broken.

3.3.2 "Working Draft at last call...judged to be stable enough". On
what grounds has this been judged to be stable enough? To date, and to
my knowledge, no one has implemented the LC specification and that
specification went to LC with known issues (which were marked as such
in the published spec). The current editor's draft of the W3C's P&C
contains over 100 changes, some of which are very significant: for
example, the inclusion the addition of <preferences> element, a
reworking of the <access> element, a revamped i18n model that is
completely incompatible with the one in the LC document, the addition
of <screenshot>, etc.

Also, the following constitute forks to the W3C specification:
* inclusion of a BONDI format version identifier within a package configuration;
* qualitative parameters relating to the management of the Widget's
presentation or lifecycle;
* quantitative parameters indicating the device or network resources
consumed by the widget.

Note that the W3C's P&C specification allows for extensions, but
cautions against them: "For the sake of interoperability, extensions
to the configuration document are NOT RECOMMENDED." I address each of
the listed extensions above individually with the aim to show that
their are unnecessary or open to abuse in some of the paragraphs
below.

As Ikivo's review pointed out, it is wrong to say "the BONDI namespace
is expected to be bound to the bondi identifier". BONDI cannot dictate
how XMLNS's are used, it is completely valid for a developer to call
the namespace prefix whatever they like (and bind it locally to other
elements if they so choose).

Why must the BONDI element be an immediate child of the widget
element? Does that means that the following is invalid?

<widget xmlns="" xmlns:bla="bondinamespace">
<name>..</name>
<bondi/>
</widget>

The use of the term "immediate" is confusing.

Why does the bondi element require XML Schema at all? As Ikivo's
review already pointed out, is it expected that a widget user agent
support XML Schema or do something meaningful with that schema? It
also seems wrong to associate a schema with a document through an
attribute. If it serves no function in the processing of the
configuration document, we recommend that XML schema be dropped all
together. BONDI can provide the schema separately for whatever reasons
it believes such a thing would be used. Better still, if the bondi
element remains, and we would argue it shouldn't, BONDI should extend
the W3C's relax NG schema instead.

The presentation element makes no sense to us. It seems to have
nothing to do with presentation of a widget, but more to do with
"operation". If anything, this element should be called <operation
type="background hidden etc"/>. However, our position is that it
should not be a requirement that BONDI user agents support background
processing or hidden modes in the way being specified here. If hidden
relates to a window mode, then it should be defined in the W3C's
Widget Window Modes spec.

The <resources> element, and it's <network> and <storage> companions,
is superfluous and easily subject to abuse (i.e., if I know people
look at this as part of the download decision process, then I can just
lie and say it uses a minimum amount of space/data). This kind of
thing should be left to the Widget engine to report at runtime (e.g.,
An engine should report "Widget X is currently using x megabytes of
your device, and has sent Y bytes of data per day on average"). This
should not be left up to developers. Those elements serves no useful
function. As Ikivo review pointed out, the use of the word resource
here is also confusing with Web Architecture terminology.

The <target> element is particularly problematic. How would it be used
for google maps, for instance. Would authors have to list every
possible sub-domain that is used by googles servers when serving map
images? What if the author does not know what those servers are or if
their sub-domains change dynamically over time? What happens when
targets are not listed, given that they are optional? Etc.

Section 3.4.2 references the _Editor's Draft_(!) of the Widgets 1.0:
Digital Signature specification (see [12]). This should be fixed ASAP!
Although that document is reaching maturity, it is still changing on
an almost daily basis.

AS-0310 - discusses issues with an old draft of the Digital Signatures
specification. Those issues should be raised at the W3C. It is not
clear what an implementation is supposed to do here.

(note that 0320-0330 discusses things that are already mandated by
Widgets Dig Sig, there is no need to replicate that in the
Architecture document.)

0340 is a mobile specific requirement, and should not be part of the
architecture.

0350 is already handled by Widgets Dig Sig.

Section 4.3.2
As noted by Ikivo's review, the BONDI's <feature> violates the W3C's
definition of the feature element by introducing a version and an id
attribute in the BONDI namespace. If versioning of APIs is required,
this should be done through the name attribute (as part of the URI).
The W3C's feature element does not have an "id" attribute, it's called
"name" instead. We encourage BONDI to drop version.

We cannot see any advantage in defining urns for feature identification.

AS-0360-0380 just seems to replicate what the W3C's P&C already
states, apart from 0380, which talks about the version attribute.

Section 4.3.3
This section is at odds with what is being specified in the Widgets
1.0 API specification. In the W3C model, features are not requested,
they are just there or not. Using parameters to request particular
feature capabilities seems like a security hole. What capabilities
will be enabled in a feature should be declared in the config document
through the URI string. It is unclear what an "associative array" is,
IFAIK, there’s no such thing as an associative array in
ECMAScript/Javascript. As already indicated by Ikivo's review, please
use a defined ECMAScript data type.

Section 4.3.3 also talks about a "website"?

AS-0408,0490 should really define an exception type, for interoperability.

-- 
Marcos Caceres
http://datadriven.com.au
Received on Friday, 20 March 2009 15:30:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT