RE: [Widgets] LCWD#3 comments (2)

Hi Marcos,

>>3. say that parameter is allowed, but if it includes an encoding
>>parameter, then @encoding beats it (or the other way around).
OK

" let start file encoding be the value of the last
supported parameter components whose purpose is to declare the
character encoding of the start file."
Should be
" let start file encoding be the value of the last
supported parameter component whose purpose is to declare the
character encoding of the start file."
(components -> component)

>>heh, good point (I honestly don't know which fools let me be a spec
>>editor; I'm soooo obviously  not qualified! just hope no one will
>>notice :) )
;) Keep up! You are doing a great job! I am just reviewing :)

>>What we should do here is quickly ask Adam Barth to take a look at
>>what we have specified and make sure it is ok.
OK.

For the purposes of my LC comments, I am satisfied with your response up to the next line.

>>> It is unclear why the valid-MIME-type production requires “parameter”.
I will send another email with comments on this grammar.

Thanks,

Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
Sent: Thursday, November 19, 2009 2:54 PM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [Widgets] LCWD#3 comments (2)

Hi Marcin, All,

Marcin has identified an issue with the spec that requires input from
people that know the MIME. Please see the changes I have proposed to
the spec below.

2009/11/18 Marcin Hanclik <Marcin.Hanclik@access-company.com>:
> 5.3 (grammar: I hope these are final corrections L )
>
>
>
> [*folder-name]
>
> Should be
>
> *folder-name
>
> Since the current form makes it optional twice

Right. Fixed.

>
>
> Zip-rel-path
>
> file-name/
>
> could be
>
> file-name /
>
> (note the space before ‘/’)

Noted and fixed :)

>
>
> safe-char
>
> I suggest putting the ‘/’ sign at the end of each line instead of at the beginning
>

Done.

>
> 7.4
>
> Media type attribute
>
> It is unclear why the valid-MIME-type production requires “parameter”.
>
> “parameter” could specify the charset and that could conflict with the @encoding attribute of the <content> element.
>

This is true and a really good point. It was actually the reason I
included the parameter part (so you didn't need the encoding
attribute).  And also because parameters could appear, in which case I
didn't want those strings to be treated as invalid - and hence make
the whole widget invalid! However, given that I forgot to specify the
behavior for the situation you describe, we should either:

1. kill the parameter bit - using the ABNF you suggest below.
2. say that it is allowed, but left up to the implementation.
3. say that parameter is allowed, but if it includes an encoding
parameter, then @encoding beats it (or the other way around).

I don't particularly like 1, because I can imagine use cases where one
could automatically convert a web page into a widget and retain the
Content-Type: header for a resource without needing to strip out the
parameters. Having the parameters would automatically make the content
type invalid and, hence, ignored by the UA, which I don't think is
right.

I share your concerns about 2, because it is ambiguous.

I guess 3 seems like the right thing to do. I think @encoding should
win - but I don't have a technically valid reason why... maybe just
because it could serve as an explicit override.

Here is a proposed text, to go into Step 7 as part of the content
element parsing rule. I've added it to the latest draft. Please take
the time to review it.

[
[if it's ] A content element:

...

7. If the encoding attribute is used, then let content-encoding be the
result of applying the rule for getting a single attribute value to
the value of the encoding attribute. If the character encoding
represented by the value of content-encoding is supported by the user
agent, then let the start file encoding be the value of
content-encoding. If content-encoding is an empty string or
unsupported by the user agent, then a user agent must ignore the
encoding attribute.

8. If the type attribute is used, then let content-type be the result
of applying the rule for getting a single attribute value to the value
of the type attribute. If the value of content-type is a media type
supported by the user agent, then let the start file content-type be
the value of content type. If value of content-type is invalid or
unsupported by the user agent, then a user agent must treat the widget
package as an invalid widget package.

9. If the start file encoding was set in step 7 of this algorithm as a
result of processing a valid and supported value for the content
element's encoding attribute, then skip this step in this algorithm.
Otherwise, if the value of content-type is a media type supported by
the user agent and if content-type contains one or more [MIME]
parameter components whose purpose is to declare the character
encoding of the start file (e.g., the value
"text/html;charset=Windows-1252", where charset is a parameter
component whose purpose is to declare the character encoding of the
start file), then let start file encoding be the value of the last
supported parameter components whose purpose is to declare the
character encoding of the start file.

In the following example, the user agent would set the start file
encoding to ISO-8859-1 and would ignore the charset parameter used in
the type attribute.

<widget xmlns="http://www.w3.org/ns/widgets">
  <content src      = "start.php"
           type     = "text/html;charset=Windows-1252"
           encoding = "ISO-8859-1" />
</widget>

In the following example the user agent would set the start file
encoding to Windows-1252, if the user agent supports that encoding.

<widget xmlns="http://www.w3.org/ns/widgets">
  <content src  = "start.php"
           type = "text/html;charset=Windows-1252"/>
</widget>
]

> Also the valid-MIME-type could be replaced with the following from RFC4288
>       type-name = reg-name
>       subtype-name = reg-name
>     reg-name = 1*127reg-name-chars
>     reg-name-chars = ALPHA / DIGIT / "!" /
>                       "#" / "$" / "&" / "." /
>                       "+" / "-" / "^" / "_"
>
> BTW:
>
> I understand that W3CMediaReg uses RFC2046 (actually RFC2048), but RFC4288 (also BCP13) obsoletes RFC2048.
>
> So it gets blurred to me.

I don't know which reference would be correct, so lets just run with
the classic one.

>
>
> Path attribute
>
> “a valid path represent a hierarchical”
>
> Should be
>
> “a valid path represents a hierarchical”

Fixed.

>
>
> Version attribute
>
> “e.g. '1.0' is not greater than '2.0'”
>
> Could be
>
> “e.g. '1.0' is not less than '2.0'”
>

heh, good point (I honestly don't know which fools let me be a spec
editor; I'm soooo obviously  not qualified! just hope no one will
notice :) ).

> 9.1.10
>
> a) There is no step 11, <ol> was changed to <ul> after step 4.
>
>
>
> b) SNIFF spec basically specifies the algorithms for the resources retrieved from the network.
>

Correct.

> The statement relevant to P&C seems to be:
>
> “   For resources fetched from the file system, user agents should use
>
>    platform-specific conventions, e.g. operating system file extension/
>
>    type mappings.
> “

Exactly.

> Therefore it is unclear what
>
> “processing file through the [SNIFF] specification.”
>
> means (i.e. SNIFF is big, but we need just one sentence?).

Hmmm... The thing is, I assumed the content is coming over the
"network" (HTTP) even when it is being served locally. When it is not,
I assumed exactly what you copied and pasted from SNIFF would apply.
So, although you concluded that it was unclear, you still concluded
what I intended.

I based the specified behavior on Opera Unite which, from what I
understand, serves itself content from a widget package over HTTP, but
on the "server" level, talks to the widget package on it's own
proprietary protocol ("unite://" or something).

> Are we restricted e.g. to section 5 (“Unknown Type”)?

When the transport layer is using WURI, yes. I think so.

What we should do here is quickly ask Adam Barth to take a look at
what we have specified and make sure it is ok.

>
> c) The version of the SNIFF spec that is referred by P&C is 00 (by date) and it has already expired as ID.
>

Right. I will update this to the right version (for now, I removed the
date and just put "work in progress").

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


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Friday, 20 November 2009 11:30:06 UTC