Re: [widgets] Comments on LCWD #3

Hi Cyril,
Thank you for again taking the the time to review the P&C spec...
comments below.

2009/10/25 Cyril Concolato <cyril.concolato@enst.fr>:
> Dear all,
>
> I made a review of the current specification [1] and I have some comments. I realize that I'm sending these comments quite late in the process but I couldn't make an earlier review. The purpose of these comments is not to delay the publication of the specification. The purpose is more to understand the rationale behind the technical choices that have been made and to facilitate implementation.
> Here are my comments:
>
> 1. The handling of localization is different between the <icon> element and the <content> element. The <icon> element does allow element-based localization using the xml:lang attribute and it also allows folder based localization, while the <content> element only allows folder-based localization. Is it an error or can you give the rationale?
>

Removed xml:lang support (we actually did this a while ago, but in the
test suite version of the spec - this will be in the new LCWD to be
published tomorrow):

http://dev.w3.org/2006/waf/widgets/Overview_TSE.html

> 2. The use of media types.
> 2.a The <content> element defines a "type" attribute. Why doesn't the <icon> element do the same?

Yes, it probably should. No one requested this feature and [SNIFF]
(see spec for link) covers most of the use cases.

> 2.b Why is section "9.1.10 Rule for Identifying the Media Type of a File" needed? This seems akward to do type sniffing. Why not using a media type given in the configuration file?
>

Because content's @type is an optional attribute, hence you need
sniffing. There is no other way to determine the type.

> 2.c From 7.11.2, it seems that there can be several <icon> elements (zero or more) differing by their media types (SVG, PNG ...). Why is this not allowed for the <content> element (zero or one), e.g. HTML, SVG ...?
>

Please explain the use cases you have in mind (this is on the V2
roadmap, btw - but would like to hear what ideas you have).

> 3. Unpackaged widgets. Have you envisaged delivery of unpackaged widgets? Is it in the roadmap of the
> group?

If I understand what you mean, this is already supported: Google for
"Apache Wookie project" and Opera Unite.

Another interpretation of the above is:

http://some.place/widget.wgt!/some/data

That is, accessing stuff in a package as as if it was a resource via a
URI (like its done with Jar files). I personally don't think this is
good use case for widgets. If they are on a server, then they should
just be served as resources.

Anyway, I'll let you tell us what you mean.

> For example, have you envisaged registering a media type for the XML configuration file?
>

No, not yet. However, I don't think it's necessary as it can just be
served as application/xml and semantics acted upon from interpreting
the namespace.


-- 
Marcos Caceres
http://datadriven.com.au

Received on Monday, 26 October 2009 15:31:56 UTC