[
Lists Home |
Date Index |
Thread Index
]
> 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 is wrong. You *can't* express it as a schema numeric type because
the document creator must have freedom to specify the number of trailing
zero's, not the schema. Either you have to support multiple schemas
(our company policy is two decimal points of precision, while his is
four), or you have to define your own type that "looks like" a number,
but isn't.
That look-like approach is a hack. It's a hack because some folks want
to use the "value space" to get compact/efficient on-the-wire encodings,
when the schema language -- any/all of them! -- should primarily be
about the "lexical space".
Yes, X.fws might be safe, but only if you treat all element contact as
CDATA.
> 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.
No, it's a mismatch between the data-type folks and the markup-type
folks. And the data folks don't seem to realize that the current crop
of security functions requires them think like markup-type folks on the
wire.
Good luck roundtripping floating-point numbers without breaking the
signature on the purchase order.
/r$
--
Rich Salz, Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
|
