Re: ISSUE-8: MUST allow pattern on all types

----- Original Message From: <Paul.V.Biron@kp.org>

>> I don't think there is a problem when the integers match canonical
> forms.
>> Certainly your first example matches the canonical form, as does your
> second
>> one, but I'm not sure if that is the intent.
>
>> Bigger problems happen when the desired output is something like 001,
> 002,
>> 003 etc.  (e.g. \d{3}), or requiring the + or - sign (e.g. [-+]\d+).
>
> Actually, my second example did NOT match a canonical form:
...
>                     <xs:pattern value='(0+|23[284]+)?\d*'/>
...
> Note the 0+ at the start.  Well, I guess since I made it optional, you
> could ignore it...so, change that to:
...
>                     <xs:pattern value='0+(23[284]+)?\d*'/>
...
> and then it is basically the same as your \d{3} case.

Apologies for being too literal in my interpretation of your example.  I had
hoped I had conveyed that you may not have intended to match a canonical
form.

> What problem could be caused by requiring the sign?  Which was optional in
> my first example.
>
> I realize that it is not always easy to serialize some pathological
> cases...but again, I think it is unacceptable for this WG to tell
> implementors that it is OK to not support some aspect of the schema spec.

My understanding is that the document is not limiting what schema developers 
can do, but trying to capture what will lead to a good or bad experience 
using data binding technology.  Schema developers are quite at liberty to 
ignore the advice if they wish.  Such decisions can best be made with the 
document providing suitable advice.

Another thing is, if we just take a hard line that schema developers must be 
able to do all that schema allows them to do, don't we end up with a one 
line document?

> Luckily I don't have to do it...but I'm sure some smart person could write
> an algorithm that translated a schema regex into an sprintf format string,
> couldn't they?

I personally don't feel that a recommendation should be requiring behaviour
that the authors of the recommendation don't know how to do.

Patterns in general either match or not, so trial and error seems to be the 
only general option for trying to match a particular pattern.  There is 
potential to do this with an integer, where all you can really do is add 
leading zeros and try adding a plus sign.  Trouble is, this could be long 
winded because you don't know whether the pattern did not match because it, 
say, didn't have enough leading zeros, or it's just not possible to match 
the pattern.  Floating point numbers present even more of a problem.  In the 
simple case the mantissa can have leading or trailing zeros, or be limited 
to a limited number of trailing zeros, or have a leading + sign.  Similarly, 
the exponent can have leaning plus sign, have leading zeros, be E or e or 
absent completely.  I make that over 7000 possible combinations - and 
they're the easy ones.  It may be decided that the exponent should be a 
multiple of 3 (e.g. /-?\d+(\.\d+)?e-?(0|3|6|9|12)/).

This to me would suggest that a developer would get a bad experience 
attempting to apply arbitrary patterns to numerical types.

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
                         for XML to C++ data binding visit
                         http://www.tech-know-ware.com/lmx
                         (or http://www.xml2cpp.com)
=============================================

Received on Tuesday, 28 February 2006 09:28:28 UTC