roddey at roddey at
Thu Dec 10 19:55:39 GMT 1998

"At some point a determination has to be made about what languages/patterns
will be acceptable.  Should 'fifteen' also be supported?  What are the
tradeoffs in parsing complexity vs. universal acceptance and language
independance?  If the source and target of some communication using an XML
document are both humans, most of us are quite flexable (even if seeing
some form or other makes us irritated).  Give me 'fifteen' in French and
I'll be just as lost as my parsers :-)."

It seems to me that, at least for e-bidness, a very acceptable mechanism
would be to create 'canonical' representations for all the major data types
used in business. Since the documents are likely to be generated
mechanically and processed mechanically, translation from the user document
to the canonical representation for transmission, and the redigesting on
the receiving end, would be a none trivial amount of code but not horrible
relative to the benefits gained.

So, choose "[+/-]x.y" for floating point and say that's the canonical
format, period. If you want to be interchangeable for e-bidness, you use
the canonical format in your serialization of the data.

I know that doesn't do anything for the more document oriented folks, who
have a much harder row to hoe. However, dealing with the issue for e-biz
would be a big step and wouldn't be horrendous to do. It would be a matter
of buying a DLL/Java zip file for your locale that knows how to do the
translation to/from the canonical format.

There would need to be a little glue that knows how to take type
representation names from your particular Schema, and convert them to the
name of the canonical type so that the in/out processing knows how to deal
with your type names. But that wouldn't be a huge amount of work, and could
be packaged with a Schema implementation once the canonical format names
were known.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list