[
Lists Home |
Date Index |
Thread Index
]
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.
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
|
