[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Rich Salz [mailto:rsalz@datapower.com]
> Sent: Wednesday, April 14, 2004 12:28
> To: bob@wyman.us
> Cc: 'Elliotte Rusty Harold'; 'xml-dev'
> Subject: Re: [xml-dev] RE: Schema vs Schema-free
>
>
> > 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.
I partially agree here. The support for floating-point numbers and decimal
numbers in ASN.1 is rather simple, mainly for historical reasons - few
applications of ASN.1 exchange floating-point numbers. You can specify that
a component is a REAL, and can even constrain the range of the mantissa and
the range of the exponent. But an instance of a REAL cannot say how many
digits of its mantissa are significant. (DER/CER forbid trailing zeros in
the mantissa (*)). The "precision" information is simply not represented in
the encodings. In other words, variable precision is not supported by the
REAL type.
Nothing prevents you from specifying currency data as strings, though. In
this way you are safe, and the loss in compactness is small. REALs should
only be used when precision is fixed and known a priori, not when it is
variable.
I don't think the problem you mention affects other data types.
For example, a name "Maria" may or may not be considered the same as "Maria
". Some old systems will absolutely consider the two forms to be the same
value. PL/I's character string equality operator will return a '1' (true).
However, ASN.1 does not consider them to be the same any more than XML
Schema does. You can roundtrip safely in this case.
Alessandro Triglia
(*) BER does not forbid trailing zeros in the mantissa, so it would seem to
support variable precision. In reality, this is to be considered as a
so-called "encoder's option" rather than as a feature that applications
should rely upon.
> 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
>
>
> -----------------------------------------------------------------
> 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>
>
>
|
