Just a thought.

“There is a reason XML excludes these dumb terminal control codes. They are neither desired nor necessary in XML.”

The inability of XML at a native level to store ALL characters (and NO CDATA sections dont solve the problem) is a serious serious weakness in XML that has resulted in a) lower adoption than it should have, b) multiple other standards being used instead, and c) multiple reimplementations of differing and incompatible ways to encode an arbitrary binary data packet at the application layer so it can be stored in XML. This is an absolute nightmare for a serialization and data exchange format.

One of the most common frustrations i see in the development community relating to XML is that XML is mindboggling hard to use with completely arbitrary data packets. CDATA doesnt allow nesting, and XML as a whole doesnt allow a range of highly useful and important characters to be used in any way.

Now while i agree that the way MS has done this is pretty brain damaged, the claim that XML neither needs nor wants to support arbitrary chars is just BS that does not in any way match what I hear from developers wanting to use XML.

An example, a simple website want to produce an XML feed of notes entered by their users. Since these notes are user entered they can contain pretty much anything. There is NO safe way to deliver this data faithfully using XML without additional application logic to handle encoding special content.

On this level XML is broken. And I think you undermine your basic argument by repeating such nonsense. And your basic argument is valid. So undermining it isnt all that clever.

And YES, i do know the arguments against leaving them out. They were specious then and are specious now.

If somebody has a document with an 08 in it, where the 08 is supposed to represent “INVERSE BULLET”, then according to this table, this should be mapped to the Unicode character U+25d8.

Indeed, it should be called OpenBIFF.

Winter

Aren’t some of these C0 characters printing characters in some fonts? I know they used to be in the original PCs. Maybe it’s not so far-fetched that someone would use \u0008 in a document.

OOXML Obviously ain’t XML

I never read the OOXML documentation, but the name of these types gave me a bad feeling. Aren’t LPSTR and BSTR two Windows API string types? (BSTR being the COM UTF-16 counted string type and LPSTR being the C 8-bit “ANSI” zero-terminated string type.)

It wouldn’t surprise me if the source of the issues with these two string types is due to them attempting to serialize their native representation. In particular, BSTR can have embedded NULLs. Either way, it sounds like an implementation detail “leaking” into the specification.

I raised a similar issue in the US NB review of OOXML last summer. We did register one comment, US-0162, that pointed out that the “bstr” type lacked a mechanism to “escape the escape”, i.e., encode a literal value of _x0008_. This was addressed by Ecma Response 118 at the BRM. But it left untouched the other types with the same issue, like ST_Xstring and lpstr.

I would have reported ST_Xstring as a problem during the initial review, but we ran out of time,

Any XSL engine will still be able to handle escaped values in the text, just not unescape them. Sometimes that is good, sometimes it will be hopelessly bad. It depends entirely on the use.

Then again, aren’t we beyond the stage of improving this POS?

You’d think the combined might of Microsoft and ECMA would be able to produce something with fewer errors than normal specs, not the opposite…

jd

That’s not a bug, Rob, it’s a feature.