On Wed, Oct 28, 2009 at 4:23 AM, Cyril Concolato
<cyril.concol...@enst.fr> wrote:
> 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.concol...@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?
>
D'oh! I'd removed lang from the processing model (Step 7) but not from
the element definition. Thanks for spotting that! :P
Icon element now says "Localizable via xml:lang: No. Relies 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.
It's not _that_ bad. I'd trust magic numbers and file extensions over
mime types any day (though I believe that MIME types should be
respected if present). Servers are configured to serve MIME types
based on file extension anyways. There is no magic there. If it's good
enough for Web servers (and the Web has not fallen apart), then it
should be good enough for widgets.
Having said that, we do intend to add a manifest format at some point
in the future that would be based on Apache's addType rule thingy.
Something like:
<manifest>
<mime ext=".ext .xyz" type="image/gif" />
<file path="some/file" type="image/gif">
</manifest>
Or better, just plain text:
AddType text/html .asp .php .foo
file type/subtype some/path/to/file
>>
>>> 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 ?
Because:
1. 99% of the time the start file is going to be HTML - hence it
defaults to text/html
2. Browsers have pretty good heuristics built in to allow them to
sniff types (these heuristics are already interoperable and are being
standardized by [SNIFF])
3. Having to type in something redundant would annoy authors when
machines are just as capable of working out the mime type on their
own. Also, it is likely that human error would cause more issues than
sniffing (like Google's research showed that people can't spell
"language" in the <script> element). What's the point of making them
do something that they are likely going to stuff up anyway and in the
end the UA will likely just ignore what is declared? (I know I've
misspelled language a bunch of time and I'm glad it still just works).
4. And, if you really want to declare your own type then you can do so
with @type. Forcing people to include stuff is unhelpful, hence
everything but the widget element and the namespace is mandatory
(which is used by UAs to confirm that the package is in fact a w3c
widget).
>>
>>> 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.
We had this a while back, where we allowed for fallback content:
<content type="image/svg+xml" src="foo">
<content type="application/vnd.whatever.flash" src="flash">
<content src="bah.html" />
</content>
</content>
We might reintroduce it in V2 if there is demand for it in the market.
Initial implementations did not support it, so we took it out.
>>
>>> 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.
That is correct. But once on a server, it basically just behaves as if
it's just a bunch of "resources" in the traditional sense (as opposed
to files). The notion of a "widget" vanishes. Then you use traditional
HTTP means to achieve all communication/interaction/i18n.
For example, pretend Wordpress is a "widget package". On my server,
when I upgrade WordPress, the server goes and fetches the
wordpress.zip file from Wordpress.com. It then automatically
decompresses the zip file overwriting the old php files. Conceptually,
wordpress can be considered a widget (packaged app). But once it is
decompressed and runs of a web server, that notion is lost.
Internationalization then gets handled by Apache (or IIS or PHP).
Apache could be configured to replicate the folder-based i18n model
used by widgets simply enough by making use of the Accept-Language and
mapping the values appropriate resources on a /locales/ folder.
We designed the i18n model to behave in much the same way as a HTTP
server would. This is by design. If there is a mismatch, then we have
an issue.
>>
>>> 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 mentioning 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.
I might be missing something, but I don't see what value there is in
saying that something is a widget if it's unpackaged. Could just be
that I have not thought about it enough. Widget packaging is just a
nice way of wrapping everything up for distribution. If one wants to
run a widget as a "widget" (in it's packaged form), then they should
do so in a conforming widget user agent. That way, you get all the
widget APIs, etc.... then again, I can see why it might be useful.
In any case, this is all outside the scope of this specification but
will make for an interesting discussion going forward.
--
Marcos Caceres
http://datadriven.com.au
