From Doug.Mahugh@microsoft.com Fri May 18 12:28:38 2007
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Date: Fri, 18 May 2007 12:28:28 -0700
From: Doug Mahugh <Doug.Mahugh@microsoft.com>
Subject: RE: DIS 29500 Contradiction of ISO/IEC 26300, part 7
In-reply-to: <464CAECA.4050600@durusau.net>
To: "patrick@durusau.net" <patrick@durusau.net>
Cc: Dave Welsh <Dave.Welsh@microsoft.com>, Frank Farance <frank@farance.com>,
        Jerry Smith <jerry.smith@disa.mil>, Jon Bosak <jon.bosak@Sun.COM>,
        "Levine, Leonard F CIV DISA GES-E" <Leonard.Levine@disa.mil>,
        Norm Walsh <ndw@nwalsh.com>, "Lynne A. Price" <lprice@txstruct.com>,
        Rex Jaeschke <rex@RexJaeschke.com>,
        Richard Barber <Richard.Barber@mindjet.com>,
        Robert Weir <robert_weir@us.ibm.com>,
        Steve Carton <steve.carton@retrievalsystems.com>,
        Tim Schoechle <timothy@schoechle.org>,
        "Mason, James David (MXM)" <masonjd@y12.doe.gov>,
        Kevin Trainor <ktrainor@ligent.net>,
        Eduardo Gutentag <Eduardo.Gutentag@Sun.COM>
Content-language: en-US
Accept-Language: en-US
Thread-topic: DIS 29500 Contradiction of ISO/IEC 26300, part 7
Thread-index: AceYxOvnIaSriEBLSKuRmFmBmKoFaAAvXarA
acceptlanguage: en-US
X-PMX-Version: 5.2.0.264296
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 

Hi Patrick,

My reply was focused on your first assertion at the beginning of the first of those seven emails (which I quoted), and I didn't actually mention or respond to your conclusion regarding taking a specific position on the question of contradiction.  My point was that your initial claim was incorrect, and that's why I quoted it and not your conclusion.

And in response to both you and Rob, I'd just like to say that I stand by that statement.  Custom tagging or custom metadata don't address the specific architecture used by Mindjet and other solutions, which use the Open Packaging Convention to embed existing XML instances in the package with no interleaving of document-format markup and business data.

But here's the more important question, it seems to me: why are we having this discussion at this point in time?  After there being no discussion of contradictions at all during our call that took place within the 30-day perceived contradiction period, why has this suddenly come to the fore?

We spent the call Monday discussing procedural issues, and now we're discussing whether we're ready to reach consensus on a comment about contradiction requiring presentation of mappings in the specification, as well as discussions of how DIS 29500 compares to ISO/IEC 26300.  These are all interesting discussions, but if we truly do have a large number of technical issues before us then I think we need to be more disciplined about actually discussing them. I'd suggest that we assign a "comment number" to this issue, along with all the items just submitted by Rob, and we proceed to see which ones can be dealt with via email before our next telephone call.

>From the perspective of the job we've been assigned, evaluating any perceived technical issues and/or deficiencies in the spec, it seems to me that your point revolves around a problem with a specific non-normative statement in the Explanatory Report, which you quoted in Part 6 of your email: "To the best of our knowledge, it is the only XML document format that supports every feature of the binary formats."  If that's the problem, let's put it on the list and move forward.  My personal feeling is that the best resolution would probably be to just suggest that sentence be removed -- it sounds like marketing fluff, frankly, and has no bearing on questions of implementation.

- Doug


-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net]
Sent: Thursday, May 17, 2007 12:37 PM
To: Doug Mahugh
Cc: Dave Welsh; Frank Farance; Jerry Smith; Jon Bosak; Levine, Leonard F CIV DISA GES-E; Norm Walsh; Lynne A. Price; Rex Jaeschke; Richard Barber; Robert Weir; Steve Carton; Tim Schoechle; Mason, James David (MXM); Kevin Trainor; Eduardo Gutentag
Subject: Re: DIS 29500 Contradiction of ISO/IEC 26300, part 7

Doug,

I tried to structure my posts so that we could develop answers that will
be useful for this issue as well as others.

It would be helpful to know how you would answer the other questions
that I posed in this thread. Simply disagreeing with my conclusion is
interesting but doesn't tell us anything about what you thought about
the way I arrived at it.

Doug Mahugh wrote:

>Hi Patrick,
>
>In my opinion, the statement "the purpose of DIS 29500 is to provide an XML representation of Microsoft Office 97-2003 binary formats" is correct but incomplete.  So your entire argument put forth in the series of seven emails this morning starts from a misleading and incomplete assertion.  I'll try to explain ...
>
>
>
It wasn't my intention to be misleading. I was working from the
Explanatory Report as filed by Ecma. I don't doubt there are other views
about what is important about DIS 29500 but those views don't represent
what has been stated by the submitter of the proposal.

I think to be fair to everyone we need to work from what DIS 29500
actually says and not what we might have said were we writing it in
response to some comment.

Consider that all of "Section 2: Purpose For The Standard" in the
Explanatory Report never directly mentions the "custom schemas" you
outline for us below under Section 2.

It does mention binary or legacy formats in 10 out of the 17 sentences
in Section 2, so I think my characterization is a fair one. (Section 2
never mentions custom schemas directly or by any indirect reference that
I recognize.)

If my take on DIS 29500 is "misleading and incomplete" then it is on the
basis of the Explanatory Report filed by the submitter.

Are you saying that the Explanatory Report is "misleading and
incomplete?" ;-)

True enough, the Explanatory Report finally has a section on "custom
schemas" at Section 4.7 Integration with Business Data but you really
have to hunt to find it. (To be complete, it also mentions on page 3
"custom XML data, page 4 "custom schemas," and of course, Section 4.7.
There may be some implied references that I missed but I think that is
fairly close to being complete.)

>DIS 29500 serves other purposes that are not served by ISO/IEC 26300, especially in the area of integration options for external schemas.  (By "external" I mean schemas that are not part of the spec itself -- in common usage we tend to call these "custom schemas" as opposed to the "reference schemas" in DIS 29500).
>
>
Well, actually one has to search for "custom XML schemas" to find the
parts you are describing.

Part 1 - 0 occurrences

Part 2 - 0 occurrences

Part 3 - non-normative so not searched

Part 4 - 6 references, 2.15.1.5, 7.5, 7.5.2.3, and 8.

Part 5 - 0 occurrences

About 5 pages out of 5,560 pages of text. (I excluded Part 3 since it is
entirely non-normative.)

>I teach Open XML workshops for developers, and the capability to embed custom schemas into documents is something many developers find useful and exciting, and it's something ISO/IEC 26300 has never made any attempt to address.  For example, I routinely show developers how we can create a schema on the spot (one that has never existed before), and embed instances of that schema in Open XML documents and/or tag the content of Open XML documents with that schema.
>
>
>
Well, I won't use the phrase "misleading and incomplete" concerning your
statements about ISO/IEC 26300 since that implies intent but I will note
that they are *incorrect*.

If you look at 1.5 Document Processing and Conformance you will see:

> Documents that conform to the OpenDocument specification MAY contain
> elements and
> attributes not specified within the OpenDocument schema. Such elements
> and attributes must
> not be part of a namespace that is defined within this specification
> and are called foreign
> elements and attributes.


You should also note that arbitrary metadata is also allowed by ISO/IEC
26300.  (see 2.2.1 Pre-Defined vs. Custom Metadata.)

If you want to say that handling of custom schemas could be improved in
ISO/IEC 26300 I have no doubt that is probably a true statement. But
then as Rex has mentioned recently, all standards can be improved. But
that is a different claim from saying that ISO/IEC 26300 does not handle
custom schemas.

>This has no impact on interoperability within the world of simple desktop applications (such as word-processing programs), because the documents are still well-formed Open XML and consistent with the DIS 29500 spec.  As a simple example, the tagging of content with that custom schema only adds customXml elements to the document body, which are part of the WordprocessingML schema, and the custom elements appear as attributes of those customXml elements.  This allows the document body to be well-formed WordprocessingML even though custom semantics have been added, just as microformats (with their encoding of semantics in class attributes) allow HTML documents to continue to be well-formed XHTML even though non-HTML semantics have been added.
>
>But -- and here's the benefit that makes custom schema support so useful to developers -- the embedding of those customs schemas enables interoperability with other types of systems (custom systems typically) that is not possible through the use of any other existing standard, including ISO/IEC 26300.  Other systems can read content from the document based on their own semantics, as defined in schemas external to DIS 29500, and that makes many types of solutions possible that could never be implemented with ISO/IEC 26300.
>
>
>
Since I have noted the appropriate sections from ISO/IEC 26300 I am
looking for a correction of your statement: "...makes many types of
solutions possible that could never be implemented with ISO/IEC 26300."

You may, of course, prefer that such solutions be done using DIS 29500,
and that is your choice, but to say that they cannot be done with
ISO/IEC 26300 is simply incorrect.

>Consider Mindjet's integration between Word 2007 and their Mindmanager product, which has been shipping since late last year.  They embed instances of their own proprietary schemas into a DOCM, enabling lossless round-trip interoperability between the two products.  Sure, they also throw some VBA macros and other stuff in there, but that has nothing to do with the core architecture of the solution.  As an example of that, you can do a lossless round trip between Mindmanager and Word 2007 without ever enabling macros in Word, so that the VBA stuff and the ribbon extensibility never even happens.
>
>To use an extreme analogy (just to make my point clear), saying that "the purpose of DIS 29500 is to provide an XML representation of Microsoft Office 97-2003 binary formats" is like saying "the purpose of ISO/IEC 26300 is to provide an XML representation of a document's page-margin requirements" -- technically correct, but incomplete and therefore misleading.
>
>
>
Well, my *point* is that we must rely upon what the text as submitted
actually says.

To say that I have been "misleading" when I am accurately reporting (at
least in my opinion) what the proposal itself actually says is unfair.
If you can demonstrate some other reading of Section 2. Purposes For The
Standard I would be very interested to hear your evidence for another
reading.

Note that I quoted and/or referenced the portions of the proposal upon
which I relied for my reading. I would appreciate the same courtesy in
return.

You have to remember that I come from a background in both law and
biblical textual criticism. In both professions we focused rather
carefully on the "text" and not what we would like for it to say (or at
least we tried to, can't say we always did).

Hope you are having a great day!

Patrick

PS: I would appreciate answers to the earlier parts in this thread. I
did try to structure it rather carefully so we could uncover places
where we agree and where we don't. I think that will be very helpful as
we develop comments for this proposal. In part it will avoid our having
to go back over old ground once we have agreed on particular points.
What those points will mean ultimately in terms of a US position I don't
know. I think it is too early in the evaluation for anyone to have a
fixed position on the proposal. (That is just a personal opinion, your
mileage may vary depending on who you ask.)

PPS: BTW, you never actually addressed the proposed resolution of the
comment in my post. Just in case you forgot to do so.

>- Doug
>
>-----Original Message-----
>From: Patrick Durusau [mailto:patrick@durusau.net]
>Sent: Thursday, May 17, 2007 5:41 AM
>To: Dave Welsh; Doug Mahugh; Frank Farance; Jerry Smith; Jon Bosak; Levine, Leonard F CIV DISA GES-E; Norm Walsh; Lynne A. Price; Rex Jaeschke; Richard Barber; Robert Weir; Steve Carton; Tim Schoechle; Mason, James David (MXM); Kevin Trainor; Eduardo Gutentag
>Subject: DIS 29500 Contradiction of ISO/IEC 26300, part 7
>
>Greetings!
>
>I think based on the foregoing we should take the following position:
>
>That an apparent contradiction exists between DIS 29500 and ISO/IEC
>26300 and for that reason we should vote no with comments as follows:
>
>****
>
>Comment:
>
>The US NB perceives a contradiction between DIS 29500 and ISO/IEC 26300.
>That contradiction can be resolved by the following steps:
>
>1. Ecma discloses and includes in DIS 29500, a normative mapping from
>the binary formats of Microsoft Office 97-2003 to the XML format it defines.
>
>2. Ecma demonstrates that the mapping from #1 cannot be achieved with
>ISO/IEC 26300. (Allowing for responses by NBs or other interested parties.)
>
>If Ecma provides the mapping requested in #1 and demonstrates that
>ISO/IEC 26300 cannot map the information in question in the XML format
>it defines (#2), considering any contrary suggestions, then the US NB
>will change its vote on this issue to yes.
>
>****
>
>I think that this approach takes the issue away from the "blog
>collective" and places it on firm technical grounds. We may still
>disagree on some points but I trust the depth of experience with XML
>represented in V1 will lead us to largely the same conclusons. Or enough
>so that we can reach a consensus on the comment and proposed resolution
>(assuming we don't agree on every minor point).
>
>Hope everyone is having a great day!
>
>Patrick
>
>PS: Question: I have been told but don't know of my own personal
>knowledge that the binary formats of Microsoft Office 97 - 2003 may have
>changed with service pack releases. Can someone confirm that information
>or provide a pointer to the answer? If that is true, a normative mapping
>would have to account for those changes.
>
>--
>Patrick Durusau
>Patrick@Durusau.net
>Chair, V1 - Text Processing: Office and Publishing Systems Interface
>Co-Editor, ISO 13250, Topic Maps -- Reference Model
>Member, Text Encoding Initiative Board of Directors, 2003-2005
>
>Topic Maps: Human, not artificial, intelligence at work!
>
>
>
>
>
>
>

--
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work!


