OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] RE: Schema vs Schema-free (was: RE: [xml-dev] XMLBinary Ch

[ Lists Home | Date Index | Thread Index ]

On Thu, 2004-04-15 at 03:03, Bob Wyman wrote:
> Rich Salz wrote:
> > Parts of X.fws concern me -- I am thinking of the 
> > round-trip from XML for something like <error-rate>.500
> > </error-rate> going to a local number, out via 
> > ASN.1/DER as an IEEE float, and back.  Along the way
> > it's all too likely to end up as .5, which will 
> > break my digital signature -- and quite rightly, 
> > since trailing zero's are semantically significant.
> 	I must admit that I get a little miffed whenever this kind of
> objection arises. Certainly, there is a real problem being described,
> however, it *isn't* a problem with X.fws or any of the schema-based
> alternatives to XML. Rather, the problem is that the schemas are
> underspecified. If, as you say, trailing zero's are significant, then
> that information should be expressed in the schema. If it was
> expressed in the schema, then any schema based alternative should
> honor the schema and pass along the tailing (or leading) zeros.

i've always supported a "counter" type for all those digit only strings
of fixed width (using leading zeroes). and only allow set, increment,
and decrement operations on them. ie adding, subtracting, multiply,
dividing are meaningless. eg what is the sum of two zip codes?

floating numbers are much more interesting. given all we know about
numerical analysis i've always wondered why we don't store numbers first
as a bcd version of floating point, second with a number of significant
digits component (like we use the exponent), and third with an error
estimate. we know enough to include in modern processors the ability to
update these extra attributes while calculations are being done and
enough about error management to use error estimates to minimise error
propagation during calculations. then printing or binary -> text
conversions could give much better answers without the trickiness we use

i've used some of these techniques to maintain numeric accuracy in our
calculations and it's interesting that even without processor support it
doesn't slow things down much but  can significantly improve accuracy. i
haven't experimented with it in xml yet but it is on my agenda - at
least for passing numbers as eg <value places="2">50</value> : 50.00 or
<weight exponent="2" significant_digits="4">1</weight> : 100.0

just ideas at the moment and the numeric processing has to understand


> 	This "problem" that some people attribute to X.fws and similar
> systems is really a problem with XML Schema, RelaxNg, etc. The fact
> that it becomes more obvious when you have a system like X.fws that
> relies on schema's being accurate doesn't change the fact that the
> problem exists even without using something like X.fws. For instance,
> if I (as a coder) see an XML Schema that tells me something is a
> "Float", "Decimal" or "Double", then no one should be surprised if I
> read the XML Schema specification and treat the data as defined there.
> Thus, for doubles, leading and trailing zeros are prohibited. For
> Decimal and Float, leading and tailing zeros are optional but are not
> defined to have meaning if present. 
> 	Perhaps what is required here is the definition of a new facet
> for at least one of these types that would flag the trailing zeros as
> signficant.
> 	Of course, an alternative is to simply define the type of a
> field to be a string and then constrain it to contain only numeric
> values or some number-like pattern. If this is done, then none of the
> schema-based processors will do anything other than pass the data
> through as it is found in the record.
> 	In summary: The problem here isn't X.fws, ASN.1, etc... -- the
> problem, if any, is that the Schema language isn't expressive enough
> or that people are using the wrong data types in their schemas. If
> X.fws is used with properly defined, expressive schemas, these
> problems will not arise. 
> 		bob wyman
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS