Re: [xml-dev] Was OOXML's problem that it should have used JSON not XML?

Sounds good. Sorting out what a character is --when using old pre-unicode non-ascii fonts-- must be tricky.

I understand that, in the case of standards documenting pre-existing technologies like ISO/IEC 29500-1, the technology leads and the standard follows.

But now, after 10 years, have there been any cases where the working group at ISO said "You really need to make this change or this addition!" that was not on Microsoft's agenda, and they agreed to support it in Office? I.e. where the standard process lead and the technology followed? (My expectation would be 'yes' for low-level details and 'no' for features.)

I am not asking for any "gotcha" reasons, but I think there is a "public interest" in understanding the general interaction between the ISO working group and Microsoft (I don't know it), and seeing what the longer-term benefits of the ISO project has been. (As distinct from institution interaction of them showing up to meeting, sponsoring the editor, etc.)

When OOXML was adopted as a standard at ISO, it was on the proviso that there would be an ongoing maintenance process: you have given the example of the I18n, but has it been much use elsewhere. My subjective and distant impression is that the influence has been mainly on the value-add areas of interest to governments, such as signatures, rather than say the text processing core (though your mention of fonts is evidence to the contrary...): is that right?

Regards

Rick

On Wed, Jan 24, 2018 at 2:22 PM, MURATA Makoto <eb2m-mrt@asahi-net.or.jp> wrote:

>(XML-DEVers may not be aware, but one of Murata-san's jobs for the last 10 years has been diligently working through the QA on ISO OOXML, trying to keep up with a moving target, correct where the initial documentation was wrong or speculative or incomplete, and making sure it has the information that stakeholders --such as non-MS developers-- require

There have been many improvements. One I18N-related improvement is clarification of the process of choosing font slots for characters. This process was very unclear when non-ASCII characters are used. The revised process in ISO/IEC 29500-1 considers not only Unicode code points but also some attributes, hint, lang, cs, and rtl. This (extremely important, IMHO) improvement was achieved by MS experts and Suzuki-san from Hiroshima University.

Regards,
Makoto

2018-01-24 11:15 GMT+09:00 Rick Jelliffe <rjelliffe@allette.com.au>:
Hans-Juergen: Yes, the difference is perhaps more in people's expectation of what the information language promises.

Michael Kay: But who would process OOXML using XSLT in that way? I have built several systems that generate OOXML, and one that reads it and substitutes some values, but I think XSLT (certainly 2.0) is often the wrong technology for complex processing of OOXML inputs, for example because of the flatness, the ZIP, MCE, versions, and the relationships files adds to the indirection. I don't think support of expressing "semantic relationships" was ever a goal for OOXML (especially since the i4i case when MS had to disable some XML support).

Doesn't all it means in a general purpose language with JSON is that you would have to adopt a particular programming pattern when iterating throught the JSON tree: you maintain your visitation stack to allow parent::* access and make indexes to allow keyed refences?

I know what you mean by bottom-up versus top-down, and I am not sure that is exactly the case. The original XML format for Word 2003 was top-down and more like early ODF-like (like a neater RTF in XML), but when the got down to the nitty gritty it got unworkable to proceed, so they had to start again. What they did the second time around was have a stronger top-down design patterns [Open Packaging/ZIP, macros (Markup Compatability and Extenions), versions, relationships, separation of concerns with stylesheets and graphics etc in separate files, the properties pattern of attributes) and then tried to pour the their binary format into that, top-down. It may look like bottom-up chaos if you are just expecting a single file, but is systematic. (And then, the way of all flesh, when these extractions failed or were not developed in time, you ended up with lots of bottom-up carbuncles. SNAFU.)

I think we have corresponded before that I think XSD should not even be classed as a "web" technology because it does not allow validation of webs of documents-- it is a file technology: XSLT 1 at least had the document() function, and XSLT 3 has a much stronger story as a web technology with xsl:source-document and xsl:collection etc. Consequently when you get to something like OOXML, the schemas provide no validation between documents in what is a highly linked collection.

Murata-san: Oh, I am not suggesting OOXML be replaced by JSON now! Yikes!

It seems there is a schema language for JSON, JSchema, and there is a converter from XSD to JSchema. And, yes, a large data structure or document needs some method of validation. The work and information required would not be much different.

But does anyone who implements OOXML consumer applications actually read it into a DOM with the XSD and use the PSVI? (Or does anyone use the schemas for dynamic data binding?) I suspect developers would use the schemas to generate code (i.e stub classes for import functions) and then maintain the code by hand. Do you have a feel for this?

(XML-DEVers may not be aware, but one of Murata-san's jobs for the last 10 years has been diligently working through the QA on ISO OOXML, trying to keep up with a moving target, correct where the initial documentation was wrong or speculative or incomplete, and making sure it has the information that stakeholders --such as non-MS developers-- require. Very important work, IMHO. )

Regards
Rick

--

Praying for the victims of the Japan Tohoku earthquake

Makoto