RE: RE: Schema vs Schema-free (was: RE: XML Binary C
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format