From patrick@durusau.net Thu May 24 02:33:31 2007
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Date: Thu, 24 May 2007 05:32:55 -0400
From: Patrick Durusau <patrick@durusau.net>
Subject: Re: Scope-Durusau-11, NamingDIS29500-Durusau-12, VML-Durusau-13,
 Drawing-ML-Durusau-14, OPC-Durusau-15
In-reply-to: 
 <FC0A1636BA321449A3FC8804A20F6CFD4B9A7205A2@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: 1179999198-5969005e0000-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: 1179999198
X-ASG-Whitelist: Client
X-ASG-Orig-Subj: Re: Scope-Durusau-11, NamingDIS29500-Durusau-12,
 VML-Durusau-13, Drawing-ML-Durusau-14, OPC-Durusau-15
X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at insimail.com

Doug,

Doug Mahugh wrote:

>Hi Patrick,
>
>Thanks for your comments.  It's quite a bit to digest, but I'm working my way through them.
>
>One thing that seems to be a recurring basic premise here, which we've discussed before, is the view that DIS 29500 exists to specify an XML representation of a specific pre-existing binary format.  As I've explained earlier, I don't agree with that premise.
>
>  
>
Well, note that I did not say the *only* purpose of DIS 29500 was to 
represent a specific pre-existing binary format.

The question I was trying to raise, perhaps inartfully, was one of scope.

I have been rethinking the contradiction thread more generally and you 
may be surprised to find that I have reached a different conclusion, but 
largely based on grounds with which you will disagree. ;-)

I haven't formally cast this into prose so understand that some of the 
finer points may change.

One of the purposes (I would argue the major purpose) of DIS 29500 is to 
create an XML representation of a pre-existing binary format. One that 
does not use the hierarchical structures of XML but is instead a 
paragraph based structure that has relationships to other information. 
To no small degree, I suspect this represents the logic upon which much 
of the installed base of Office products is based.

To the extent that DIS 29500 is an XML representation of an *existing* 
document model, it escapes from contradiction because what else would a 
faithful representation do? It could not very well pick some other 
document model as that would not accurately reflect the binary format 
which it seeks to represent in XML. My very tenative conclusion is the 
the "contradiction" argument concerning other ISO standards falls by the 
same reasoning. Yes, the XML representation may be inconsistent with 
existing ISO standards but then it is a *representation* of an existing 
format and therefore faces a different burden, that of being consistent 
with the binary format it seeks to represent.

That is one aspect of DIS 29500. And to my mind, is a large enough scope 
for one standard, or at least one part of a multi-part standard.

Another aspect of DIS 29500 is your custom schema (5 normative pages out 
of over 5,000+) material. And no doubt that is an important five pages 
and I would agree it is an important mechanism.

However, creating a standard that enables the relating of material in 
custom schemas to the XML representation of a pre-existing binary 
format, is a different task than an XML representation of a pre-existing 
binary format. Yes?

That is to say that yes, it is a worthwhile thing to do and standardize, 
but it is not the same task as the one we had before. Either it should 
be in a different standard or a different part of the same standard. 
(You can ask Jim Mason about multi-part standards. Each part has its own 
scope even if it is designed to work with other parts of the same standard.)

Another aspect of DIS 29500 is the DrawingML part. Again, no question 
that it is an important thing to have and to standardize, but being 
useful (or in your case desired) isn't enough to lump it together with 
other material for standardization. And yes, it is clearly designed to 
work with the XML representation of the pre-existing binary format but 
that doesn't mean that it all goes into one kitchen sink sort of 
standards design.

I suspect, but cannot say since I have gotten no responses on my 
question about MathML, that the reason why DIS 29500 apparently 
redefines much of that in the math section is make it fit into the XML 
model that was created to represent the pre-exising binary format.

I realize you may still disagree about the degree to which the core of 
DIS 29500 is an attempt to represent a pre-existing binary format but it 
would be more useful to know why you disagree? Yes, other parts do exist 
and as I suggested in my comments and here, a properly defined scope 
would at least put those in separate parts of one standard if not in 
separate standards. (The question of a multi-part standard versus 
separate standards is largely a matter of judgment and I have no real 
strong feelings on that one way or the other.)

I don't think it advances the case for DIS 29500 to contend that it 
really has nothing to do with pre-existing binary formats for office 
documents. If that were the case, then contradiction with ISO/IEC 26300 
is virtually assured. I can only go by what the documents actually say 
and if you can find some part that denies what I have suggested is the 
case, I would be really interested in seeing it.

*This isn't a question of pro or con DIS 29500 but of understanding the 
scope(s) of its many parts and then judging each one on it own. That is 
what scope enables us to do.*

Properly scoped, we could separate out the parts (I assume you may 
concede that some part of DIS 29500 is for representing pre-existing 
binary formats) that are for representation of a pre-existing format and 
say: Well, true they may disagree with or contradict other ISO standards 
but, since it is the standardization of an XML representation of a 
pre-existing format and its rules, ok.

Scope is what enables a sane discussion of *a* standard and it 
relationships to other standards.

And properly scoped, it will also allow us to evaluate what DIS 29500: 
Part 1: XML Representation Pre-Existing Binary Format, has to say for 
itself.

For example, the syntax only conformance clause. That is probably only 
necessary with  this hypothetical part one because it is probably 
unknown if not unknowable what semantics various applications have 
applied to the pre-existing binary format.

A syntax only conformance clause for Part X: DrawingML, would be very 
dumb. It is new material and should have a clearly defined syntax and 
semantics.

Not to mention that breaking DIS 29500 into properly scoped parts would 
make it a lot easier to standardize while not impairing the ability of 
the various parts to work together.

So, you can get OPC, which I think has a lot to offer implementers but 
perhaps as a part of a multi-part standard, where each with its own scope.

I really think you need to move away from the position that DIS 29500 in 
anyway represents a useful model for a standard, however useful you may 
think the various standards therein may be. There are ways of doing 
multi-part standards where the parts are interdependent but 
concatenation isn't one of them.

Another example: DrawingML (so far as I know) has no equivalent ISO 
standard with which to conflict. Great. But that should be a separate 
question from whether any other part of DIS 29500 conflicts with some 
ISO standard. The concatenation process used to formulate this standard 
prevents that sort of granular evaluation, mostly because DIS 29500 
represents several related standards or parts of one standard in one 
rather large text.

I do think we need to make more use of the mailing list, starting with 
Rob's comments that are up for discussion next week, so that we can make 
effective use of our time on the phone.

Hope you are having a great day!

Patrick

PS: While I realize you probably still disagree about the representation 
of a pre-existing binary format being one of the purposes of DIS 29500, 
I am working on a general comment on contradiction that lays out the 
foregoing with more precision and answer the question raised by other 
NBs on contradiction. Not with the silly competing standards analysis of 
Ecma, which makes no sense in a standards environment (how would you 
like to have competing standards for house outlets?) , but on the basis 
of what is being standardized, which is an entirely different question.

>In the contradiction thread, that's why I disagreed with your conclusion: I disagreed with your starting point, so couldn't agree with the conclusion that resulted from building on that starting point.  As I mentioned then, I think the custom schema support enabled by OPC is a big part of why DIS 29500 exists.  That provides new capabilities that don't exist in the binary formats or other document formats, and a high percentage of the early adopters of the format described by DIS 29500 are taking advantage of those capabilities.
>
>Here, with regard to OPC-Durusau-15, it seems you've taken that same premise -- that the sole reason for DIS 29500's existence is an XML representation of an existing binary format -- and built upon it once again.  Your argument could be paraphrased as "DIS 29500 only exists for one reason, and the benefits of OPC are not that reason, so OPC should not be included."  I disagree, of course, since I see OPC as a key element of what DIS 29500 has to offer implementers.
>
>I'll keep reading through your comments to be prepared for more discussion in our next call.
>
>Thanks,
>Doug
>
>
>-----Original Message-----
>From: Patrick Durusau [mailto:patrick@durusau.net]
>Sent: Wednesday, May 23, 2007 3:29 PM
>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: Scope-Durusau-11, NamingDIS29500-Durusau-12, VML-Durusau-13, Drawing-ML-Durusau-14, OPC-Durusau-15
>
>Greetings!
>
>This batch returns to the systemic, proposal wide issues.
>
>I think we need to give serious consideration to the question of the scope of DIS 29500 and after putting that question to rest, then decide based on that discussion, what should be in or out of DIS 29500.
>
>Hope everyone is having a great day!
>
>Patrick
>
>--
>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! 


