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

Re: Revised Proposal for Widget Signature ABNF

From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Date: Fri, 13 Mar 2009 09:22:18 -0400
Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, "Kapyaho Jere (Nokia-D-MSW/Tampere)" <Jere.Kapyaho@nokia.com>, "marcosc@opera.com" <marcosc@opera.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-Id: <3691CB30-CB2B-4C2A-80DA-46BC2F596626@nokia.com>
To: ext Marcin Hanclik <Marcin.Hanclik@access-company.com>
Yes, I made this change since we decided this week to have case  
sensitivity. Too bad we have to use literals in hex for this case ...


On Mar 13, 2009, at 4:23 AM, ext Marcin Hanclik wrote:

> Hi Jere,
>
> Although I did not author the text below, I think the literals are  
> specified as case-sensitive to match the experience from J2ME/MIDP  
> [1].
> Also case-sensitivity is more efficient when comparing strings, e.g.  
> in constrained devices, and may be important for inter-operability  
> reasons.
> I.e. the spec seems intentional.
>
> Thanks.
>
> Kind regards,
> Marcin
>
> [1] http://java.sun.com/javame/reference/apis/jsr118/javax/microedition/midlet/package-summary.html
>
>
> Marcin Hanclik
> ACCESS Systems Europe GmbH
> Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
> Mobile: +49-163-8290-646
> E-Mail: marcin.hanclik@access-company.com
> From: Jere.Kapyaho@nokia.com [mailto:Jere.Kapyaho@nokia.com]
> Sent: Friday, March 13, 2009 9:02 AM
> To: Marcin Hanclik; Frederick.Hirsch@nokia.com
> Cc: marcosc@opera.com; public-webapps@w3.org
> Subject: Re: Revised Proposal for Widget Signature ABNF
>
> Just wanted to ask if you’re using the character code terminals  
> (%x61.75 etc.) intentionally because of case sensitivity? Literals  
> like “signature” and “.xml” are allowed in ABNF [1], and they’re  
> much easier for humans to read, but the catch is that they are case  
> insensitive (and US-ASCII only). For case-sensitivity, you need to  
> specify the character codes individually, as you’ve now done. So I  
> guess that’s the intent?
>
> --Jere
>
> [1] http://tools.ietf.org/html/rfc5234#section-2.3
>
>
> On 12.3.2009 23.45, "ext Marcin Hanclik" <Marcin.Hanclik@access-company.com 
> > wrote:
> Hi Frederick,
>
> I have further, again formal comments. I am sorry for not spotting  
> that earlier.
> The terminals (section 2.3 for RFC5234) can be concatenated with a  
> dot ".".
> So
>
> author-signature-filename = %x61 %x75 %x74 %x68 %x6f %x72 %x2d %x73
> %x69 %x67 %x6e %x61 %x74 %x75 %x72 %x65 %x2e %x78 %x6d %x6 (missing  
> 'c')
>
> can be represented as
>
> author-signature-filename = %x61.75.74.68.6f.72.2d.73.69.67.6e. 
> 61.74.75.72.65.2e.78.6d.6c
>
> This format also seems to guarantee that the whole string is kept in  
> one line in majority of text editors (if line can be long enough).
> Otherwise in the final spec a white space has to be put in each  
> following line to satisfy the following rule (section 4.).
>
> rule           =  rulename defined-as elements c-nl
>                                 ; continues if next line starts
>                                 ;  with white space
>
> Thanks.
>
> Kind regards,
> Marcin
> ________________________________________
> From: Frederick Hirsch [Frederick.Hirsch@nokia.com]
> Sent: Thursday, March 12, 2009 10:15 PM
> To: Marcin Hanclik
> Cc: Frederick Hirsch; Kapyaho Jere (Nokia-D-MSW/Tampere); ext Marcos  
> Caceres; WebApps WG
> Subject: Revised Proposal for Widget Signature ABNF
>
> here is revised proposal, thanks Jere and Marcin
>
> regards, Frederick
>
> ---
>
> 1) Change section 1.1, Notational conventions as follows:
>
> Replace
> This specification uses the following syntax to define filenames.
> Characters are appended to numbers to indicate cardinality: "?" (0 or
> 1) "*" (0 or more) "+" (1 or more)
>
> A range of values is indicated by brackets, .i.e [1-9] indicates a
> digit from the range 1 through 9 inclusive.
>
> Concatenated values are written next to each other, with strings
> indicated in quotes. Thus "signature" [1-9][0-9]* ".xml"means a string
> consisting of "signature" followed by a digit in the range 1-9
> inclusive, followed by zero or more digits in the range 0-9 inclusive,
> for example, "signature12.xml".
>
> with
> This specification uses the following ABNF [ABNF] syntax to define
> filenames. Rules are concatenated by being written next to each other
> and a rule prepended by * means zero or more. See he ABNF RFC for
> details.
>
> 2) Changes in the "Naming convention for a author signature:" in
> section 5.2 Author Signatures:
>
> The following ABNF [ABNF] rule defines the format of a author
> signature file name:
>
> Replace
>
> The reserved file name "author-signature.xml"
>
> with
>
> The reserved lower-case (case sensitive) file name "author-
> signature.xml", as defined by the following ABNF [ABNF] rule:
>
> author-signature-filename = %x61 %x75 %x74 %x68 %x6f %x72 %x2d %x73
> %x69 %x67 %x6e %x61 %x74 %x75 %x72 %x65 %x2e %x78 %x6d %x6
>
> 3) Changes in the "Naming convention for a distributor signature:" in
> section 5.3 Distributor Signatures:
>
> 3a) Replace
>
> "signature" [1-9][0-9]* ".xml"
>
> with
>
> The following ABNF [ABNF] rule defines the format of a distributor
> signature file name:
>
> distributor-signature-filename = signature-string non-zero-digit
> *DIGIT  xml-suffix string
>
> signature-string = %x73 %x69 %x67 %x6e %x61 %x74 %x75 %x72 %x65
>
> non-zero-digit = %x31-39
>
> xml-suffix-string =  %x2e %x78 %x6d %x6c
>
> The signature-string rule defines the lower-case (case sensitive)
> string "signature" and the xml-suffix-string defines the lower-case
> (case sensitive) string ".xml". non-zero-digit defines a digit in the
> range 1-9. DIGIT is defined in RFC-5234 [ABNF] to mean a digit in the
> range 0-9.
>
> 3b) in first bullet, replace 'consisting of the string "signature"'
> with 'consisting of the lower-case string "signature"' and replace
> 'then ".xml", as stated by the BNF' with 'then the lower-case string
> ".xml", as stated by the ABNF'
>
> 3c) replace "BNF" with "ABNF" in the third bullet
>
> 4) Add reference to ABNF in references section, with source Jere
> noted:
>
> <dt><dfn id="abnf">[ABNF]</dfn></dt>
>   <dd>RFC 5234, <a href="http://www.ietf.org/rfc/
> rfc5234.txt"><cite>Augmented BNF
>                 for Syntax Specifications: <abbr title="Augmented
>                 Backus-Naur Form">ABNF</abbr></cite></a>. D. Crocker
> and P. Overell.
>   January 2008.</dd>
>
>
> Unless I hear otherwise by Monday, I will make this change to the
> editors draft. If you agree with the change please let me know.
>
> Thanks
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
> [1] http://dev.w3.org/2006/waf/widgets-digsig/
>
>
> ________________________________________
>
> 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.
>
> ________________________________________
>
> 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, 13 March 2009 13:24:07 GMT

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