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
<[email protected]> 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.
