Re: [widgets] Comments on LCWD #3

Hi Marcos,

Marcos Caceres a écrit :
> 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
I don't understand what you mean. The discrepancy between the two elements is still there in this version. Is your plan to remove also xml:lang on the <icon> element and rely on folder-based localization?

> 
>> 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.
Yes, I think it should, relying on sniffing does not seem to me to be a good practice.

> 
>> 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.
That's exactly my question. Why @type is not mandatory ?

> 
>> 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).
I'm thinking about widget packages which can contain multiple representation of the widgets in different formats (HTML, SVG or proprietary) so that a User Agent which does not support one of the format, e.g. HTML, can use an alternative, e.g. SVG.

> 
>> 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.
I meant that widgets may not be delivered in a package but as separate individual resources. This would imply changes to the current spec because for instance one cannot do localization by checking each locale subfolders but one can use e.g. HTTP headers.

> 
>> 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.
I see but I was mentionning it in the context of unpackaged delivery, ie. you need to identify that you're downloading a widget so the mime type could be useful.

Best regards,

Cyril


-- 
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Mutimedia/Multimedia Group
Département Traitement du Signal et Images
/Dept. Signal and Image Processing
Ecole Nationale Supérieure des Télécommunications
46 rue Barrault
75 013 Paris, France
http://tsi.enst.fr/~concolat

Received on Wednesday, 28 October 2009 02:24:38 UTC