From patrick@durusau.net Fri May 18 13:34:35 2007
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Date: Fri, 18 May 2007 16:34:03 -0400
From: Patrick Durusau <patrick@durusau.net>
Subject: Re: DIS 29500 Contradiction of ISO/IEC 26300, part 7
In-reply-to: 
 <FC0A1636BA321449A3FC8804A20F6CFD4B9A6448CC@NA-EXMSG-C103.redmond.corp.microsoft.com>
To: Doug Mahugh <Doug.Mahugh@microsoft.com>
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>
Reply-to: patrick@durusau.net
X-Accept-Language: en-us, en
X-PMX-Version: 5.2.0.264296
X-ASG-Debug-ID: 1179520458-40b800630000-F3fpwQ
X-Barracuda-URL: http://10.10.100.8:8000/cgi-bin/mark.cgi
X-Barracuda-Connect: unknown[66.110.197.207]
X-Barracuda-Start-Time: 1179520458
X-ASG-Whitelist: Client
X-ASG-Orig-Subj: Re: DIS 29500 Contradiction of ISO/IEC 26300, part 7
X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at insimail.com

Doug,

Doug Mahugh wrote:

>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?
>
>  
>
That is easy enough to answer. INCITS never asked nor forwarded DIS 
29500 during the 30 day contradiction period.

>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.
>
>  
>
Well, subject to the two week rule which Rex has mentioned for documents 
to be discussed at our meetings.

Discipline is all well and good but if you recall, we were unable to 
reach any agreement on a procedure for managing the comments on that call.

There were several suggestions made but none attracted a consensus of 
support.

It was not my intention to be "undisciplined" but on the other hand, I 
don't discussions of process to push discussions of issues to the point 
that we don't have time to adequately consider them.

>>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.
>
>  
>
I am afraid that we will have to agree to disagree on the "perspective " 
of the task before us. I have seen no citation from the Directives that 
supports the position first advanced by Rex and now repeated by 
yourself, which limits the scope of our review of the proposal.

The language I quoted seems to me to be representative of the proposal 
as a whole. That is, of course, one of the issues we will need to discuss.

Contradiction issues are not concerned with issues of practicality of 
implementation.

Since the idea of a site accessible to all V1 members (leaving aside the 
question of who else can see it) did not attract a consensus we will 
have to adopt some other method for assigning numbers to issues.

May I suggest that since we presently have no last name conflicts on the 
committee that we all simply adopt the convention of using our last name 
plus an issue number? That makes everyone responsible for keeping up 
with their own numbers. That does mean that we will have to track from 
that number to an "official" issue number later on but in the absence of 
agreement on some shared site, I don't know what else to suggest.

I deliberately broke this issue into parts, hoping that we could have 
some structured discussion of it. I can recast it in the form of a 
signle document but if all of the reasons for it are not going to be 
considered, I might as well simply state the issue and my conclusion.  
Personally I liike to know why a person has reached a particular 
conclusion. Sometimes it convinces me that my prior position was in 
error, sometimes not.

Hope you are looking forward to a great weekend!

Patrick

>- 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!
>
>
>
>
>  
>

-- 
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! 


