- From: Frederick Hirsch <Frederick.Hirsch@nokia.com>
- Date: Thu, 5 Mar 2009 12:10:27 -0500
- To: "timeless@gmail.com" <timeless@gmail.com>
- Cc: Frederick Hirsch <Frederick.Hirsch@nokia.com>, WebApps WG <public-webapps@w3.org>
I see, perhaps we can combine the text I proposed with a variant on the bnf you mentioned; signature[0-9]*[1-9].xml and add to my proposal the additional text: If a widget resource contains signatures that are not consistent in the number of digits in the names then the result of ordering will be implementation dependent. regards, Frederick Frederick Hirsch Nokia On Mar 5, 2009, at 12:03 PM, ext timeless wrote: > On Mar 5, 2009, at 9:15 AM, I wrote: >> The proposal is to only allow [1-9][0-9]*, which should solve this. > > On Thu, Mar 5, 2009 at 5:59 PM, Frederick Hirsch > <frederick.hirsch@nokia.com> wrote: >> This does not seem quite right since it requires 10 or more >> signatures? >> >> e.g. disallows signature01.xml, signature02.xml etc >> and requires signature10.xml etc > > I'm not certain about the []* notation. > > I was hoping for <leading non-zero digit> and <0 or more digits> > >> I propose the following alternative in section 5.3 >> >> Naming convention for a distributor signature:"signature" [0-9]* >> ".xml" >> >> Every distributor signature MUST have the same number of digits in >> the file >> name and use leading zeros for numbers less than the maximum >> numeric value. >> This is to enable consistent sorting. >> >> To give an example, if nine distributor signatures are expected the >> numbers >> should range from 01 to 09, e.g. signature01.xml to signature09.xml. >> --- >> >> Does this make sense? > > That'd work too, and i suppose would be easier on a sorter since it > could do an alpha sort. > Although you need to explain what to do if there are only > signature01.xml and signature1.xml, does the engine always favor the > longest string and ignore all shorter sets? > > Either way, validators need instructions, for yours it would need to > warn about signatures which have the wrong number of digits.
Received on Thursday, 5 March 2009 17:11:17 UTC