From masonjd@y12.doe.gov Fri May 25 12:42:01 2007
MIME-Version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_J3i+eybRejbg2qpGXM38cw)"
Date: Fri, 25 May 2007 15:39:33 -0400
From: "Mason, James David (MXM)" <masonjd@y12.doe.gov>
Subject: RE: Scope-Durusau-11, NamingDIS29500-Durusau-12, VML-Durusau-13,
 Drawing-ML-Durusau-14, OPC-Durusau-15
In-reply-to: <46555BC7.4070201@durusau.net>
To: patrick@durusau.net, 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>,
        Kevin Trainor <ktrainor@ligent.net>,
        Eduardo Gutentag <Eduardo.Gutentag@sun.com>
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
Thread-topic: Scope-Durusau-11, NamingDIS29500-Durusau-12, VML-Durusau-13,
 Drawing-ML-Durusau-14, OPC-Durusau-15
Thread-index: Aced5pd9EHDkJINCQMaxCe6dVTj+kABFq9ag
X-PMX-Version: 5.2.0.264296
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-OriginalArrivalTime: 25 May 2007 19:39:36.0313 (UTC)
 FILETIME=[6D244E90:01C79F04]

This is a multi-part message in MIME format.

--Boundary_(ID_J3i+eybRejbg2qpGXM38cw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

I'm jumping in again in support of Patrick's contributions. I think he =
has several valid points related to the scope of the ECMA proposal in =
terms of (1) scope and (2) construction of the standard.

Scope of the proposed standard

If you've read my comments on ODA/ODIF (ISO/IEC 8613), you can tell I'm =
having a feeling of dej=E0 vu. That does not mean that I think that the =
proposed standard deservers the fate of ODA. ODA, in spite of being =
nearly as long as the current proposal (!), was never fully implemented. =
This thing, at least, appears to have an implementation (I don't count =
the Windows and OS X versions as two implementations because they come =
from the same source). I'd rather have the IETF expectation of at least =
two working implementations before consideration for standardization, =
but one is better than what ODA got.=20
=20
I think that one of Patrick's points is that the proposed scope for this =
monster rides off in all directions, and so does the document. About all =
that holds it together is that its's an XML representation of things =
that can be put in a document. Separating the various aspects of the =
scope and then making corresponding changes to the structure of the =
document might go a long ways towards both making the document more =
comprehensible (and implementable!) and, as Patrick is trying to =
emphasize, avoid the issue of contradiction.
=20
In that what's proposed by ECMA is an XML representation for interchange =
of minimally structured compound documents (not to say simple or short =
documents), this proposal might serve as  something to plug the hole =
that 8613 was attempting to fill. But you'd have to say that was what it =
was doing by clarifying the scope.
=20
Strcture of the proposed standard
=20
Patrick suggests a multipart standard. I agree wholeheartedly.=20
=20
The present thing simply isn't a usable document. ODA, at least, did =
break things up; there were 14 completed parts, plus a bunch of stuff =
that was in process when the project was cancelled. Some of the parts =
were mildly similar to what Patrick is proposing, like two separate =
parts for graphics. Others, like the API to ODA (Part 3) were irrelevant =
here. They even had a "Formal Definition" part (10) that amounted to an =
existence proof for ODA (because they wouldn't either use a production =
grammar like SGML or BNF or produce a schema for their document). If you =
want to see what was there, look at =
http://www.iso.org/iso/en/StandardsQueryFormHandler.StandardsQueryFormHan=
dler?keyword=3DISO%2FIEC+8613&sortOrder=3DISO&scopecatalogue=3DCATALOGUE&=
scopeprogramme=3DPROGRAMME&title=3Dtrue&cacheid=3D14342456
=20
Or take a current standard in SC34 that is being revised as multipart, =
ISO/IEC 13250, Topic Maps. We approved it as a single standard, and it =
has several implementations. But we realized that it needed more than =
was in the first edition, so we're breaking it out, as well as creating =
a couple of additional standards. SC34 also has ISO/IEC 19757, DSDL, =
which likewise has several implementations for some of the completed =
parts (and indeed is referenced in the ECMA proposal, Part 4, Annex B).
=20
It is a sufficient objection to progressing a proposed standard to say =
that a document is not ready for standardization, whether one approves =
of the intent of the proposed standard or not. I contend that the =
document offered by ECMA is not ready for standardization and should be =
rewritten and restructured. (I shall offer further comments later.) This =
docment may have sufficient technical content for standardization, but =
it does not have an appropriate structure. Were it coming through a =
normal path in SC34, I would recommend holding it at the Working Draft =
level.
=20
=20
Jim Mason
=20
=20
=20


-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net =
<mailto:patrick@durusau.net> ]
Sent: Thursday, May 24, 2007 5:33 AM
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: Scope-Durusau-11, NamingDIS29500-Durusau-12, =
VML-Durusau-13, Drawing-ML-Durusau-14, OPC-Durusau-15

Doug,

Doug Mahugh wrote:

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.




--Boundary_(ID_J3i+eybRejbg2qpGXM38cw)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3086" name=3DGENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>I'm jumping in again in =
support of=20
Patrick's contributions. I think he has several valid points related to =
the=20
scope of the ECMA proposal in terms of (1) scope and (2) construction of =
the=20
standard.<BR><BR>Scope of the proposed standard<BR><BR>If you've read my =

comments on ODA/ODIF (ISO/IEC 8613), you can tell I'm having a feeling =
of=20
<EM>dej=E0 vu</EM>. That does not mean that I think that the proposed =
standard=20
deservers the fate of ODA. ODA, in spite of being nearly as long as the =
current=20
proposal (!), was never fully implemented. This thing, at least, appears =
to have=20
an implementation (I don't count the Windows and OS X versions as two=20
implementations because they come from the same source). I'd rather have =
the=20
IETF expectation of at least two working implementations before =
consideration=20
for standardization, but one is better than what ODA got. </FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>I think that one of =
Patrick's points=20
is that the proposed scope for this monster rides off in all directions, =
and so=20
does the document. About all that holds it together is that its's an XML =

representation of things that can be put in a document. Separating the =
various=20
aspects of the scope and then making corresponding changes to the =
structure of=20
the document might go a long ways towards both making the document more=20
comprehensible (and implementable!) and, as Patrick is trying to =
emphasize,=20
avoid the issue of contradiction.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>In that what's proposed =
by ECMA is an=20
XML representation for interchange of minimally structured compound =
documents=20
(not to say simple or short documents), this proposal might serve =
as&nbsp;=20
something to plug the hole that 8613 was attempting to fill. <EM>But =
you'd have=20
to say that was what it was doing by clarifying the =
scope.</EM></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>Strcture of the =
proposed=20
standard</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>Patrick suggests a =
multipart=20
standard. I agree wholeheartedly. </FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>The present thing =
simply isn't a=20
usable document. ODA, at least, did break things up; there were 14 =
completed=20
parts, plus a bunch of stuff that was in process when the project was =
cancelled.=20
Some of the parts were mildly similar to what Patrick is proposing, like =
two=20
separate parts for graphics. Others, like the API to ODA (Part 3) were=20
irrelevant here. They even had a "Formal Definition" part (10) that =
amounted to=20
an existence proof for ODA (because they wouldn't either use a =
production=20
grammar like SGML or BNF or produce a schema for their document). If you =
want to=20
see what was there, look at <A=20
href=3D"http://www.iso.org/iso/en/StandardsQueryFormHandler.StandardsQuer=
yFormHandler?keyword=3DISO%2FIEC+8613&amp;sortOrder=3DISO&amp;scopecatalo=
gue=3DCATALOGUE&amp;scopeprogramme=3DPROGRAMME&amp;title=3Dtrue&amp;cache=
id=3D14342456">http://www.iso.org/iso/en/StandardsQueryFormHandler.Standa=
rdsQueryFormHandler?keyword=3DISO%2FIEC+8613&amp;sortOrder=3DISO&amp;scop=
ecatalogue=3DCATALOGUE&amp;scopeprogramme=3DPROGRAMME&amp;title=3Dtrue&am=
p;cacheid=3D14342456</A></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>Or take a current =
standard in SC34=20
that is being revised as multipart, ISO/IEC 13250, Topic Maps. We =
approved it as=20
a single standard, and it has several implementations. But we realized =
that it=20
needed more than was in the first edition, so we're breaking it out, as =
well as=20
creating a couple of additional standards. SC34 also has ISO/IEC 19757, =
DSDL,=20
which likewise has several implementations for some of the completed =
parts (and=20
indeed is referenced in the ECMA proposal, Part 4, Annex =
B).</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>It is a sufficient =
objection to=20
progressing a proposed standard&nbsp;to say that a document is not ready =
for=20
standardization, whether one approves of the intent of the proposed =
standard or=20
not. I contend that the document offered by ECMA is not ready for=20
standardization and should be rewritten and restructured. (I shall offer =
further=20
comments later.) This docment may have sufficient technical content for=20
standardization, but it does not have an appropriate structure. Were it =
coming=20
through a normal path in SC34, I would recommend holding it at the =
Working Draft=20
level.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>Jim Mason</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>&nbsp;</DIV>
<DIV><BR><BR><FONT color=3D#000000>-----Original Message-----<BR>From: =
Patrick=20
Durusau [</FONT></FONT><A href=3D"mailto:patrick@durusau.net"><FONT =
face=3DArial=20
color=3D#000000 size=3D2>mailto:patrick@durusau.net</FONT></A><FONT =
face=3DArial=20
color=3D#0000ff size=3D2><FONT color=3D#000000>]<BR>Sent: Thursday, May =
24, 2007 5:33=20
AM<BR>To: Doug Mahugh<BR>Cc: Dave Welsh; Frank Farance; Jerry Smith; Jon =
Bosak;=20
Levine, Leonard F CIV DISA GES-E; Norm Walsh; Lynne A. Price; Rex =
Jaeschke;=20
Richard Barber; Robert Weir; Steve Carton; Tim Schoechle; Mason, James =
David=20
(MXM); Kevin Trainor; Eduardo Gutentag<BR>Subject: Re: Scope-Durusau-11, =

NamingDIS29500-Durusau-12, VML-Durusau-13, Drawing-ML-Durusau-14,=20
OPC-Durusau-15<BR><BR>Doug,<BR><BR>Doug Mahugh wrote:<BR><BR>Well, note =
that I=20
did not say the *only* purpose of DIS 29500 was to represent a specific=20
pre-existing binary format.<BR><BR>The question I was trying to raise, =
perhaps=20
inartfully, was one of scope.<BR><BR>I have been rethinking the =
contradiction=20
thread more generally and you may be surprised to find that I have =
reached a=20
different conclusion, but largely based on grounds with which you will =
disagree.=20
;-)<BR><BR>I haven't formally cast this into prose so understand that =
some of=20
the finer points may change.<BR><BR>One of the purposes (I would argue =
the major=20
purpose) of DIS 29500 is to create an XML representation of a =
pre-existing=20
binary format. One that does not use the hierarchical structures of XML =
but is=20
instead a paragraph based structure that has relationships to other=20
information.<BR>To no small degree, I suspect this represents the logic =
upon=20
which much of the installed base of Office products is based.<BR><BR>To =
the=20
extent that DIS 29500 is an XML representation of an *existing* document =
model,=20
it escapes from contradiction because what else would a faithful =
representation=20
do? It could not very well pick some other document model as that would =
not=20
accurately reflect the binary format which it seeks to represent in XML. =
My very=20
tenative conclusion is the the "contradiction" argument concerning other =
ISO=20
standards falls by the same reasoning. Yes, the XML representation may =
be=20
inconsistent with existing ISO standards but then it is a =
*representation* of an=20
existing format and therefore faces a different burden, that of being =
consistent=20
with the binary format it seeks to represent.<BR><BR>That is one aspect =
of DIS=20
29500. And to my mind, is a large enough scope for one standard, or at =
least one=20
part of a multi-part standard.<BR><BR>Another aspect of DIS 29500 is =
your custom=20
schema (5 normative pages out of over 5,000+) material. And no doubt =
that is an=20
important five pages and I would agree it is an important=20
mechanism.<BR><BR>However, creating a standard that enables the relating =
of=20
material in custom schemas to the XML representation of a pre-existing =
binary=20
format, is a different task than an XML representation of a pre-existing =
binary=20
format. Yes?<BR><BR>That is to say that yes, it is a worthwhile thing to =
do and=20
standardize, but it is not the same task as the one we had before. =
Either it=20
should be in a different standard or a different part of the same=20
standard.<BR>(You can ask Jim Mason about multi-part standards. Each =
part has=20
its own scope even if it is designed to work with other parts of the =
same=20
standard.)<BR><BR>Another aspect of DIS 29500 is the DrawingML part. =
Again, no=20
question that it is an important thing to have and to standardize, but =
being=20
useful (or in your case desired) isn't enough to lump it together with =
other=20
material for standardization. And yes, it is clearly designed to work =
with the=20
XML representation of the pre-existing binary format but that doesn't =
mean that=20
it all goes into one kitchen sink sort of standards design.<BR><BR>I =
suspect,=20
but cannot say since I have gotten no responses on my question about =
MathML,=20
that the reason why DIS 29500 apparently redefines much of that in the =
math=20
section is make it fit into the XML model that was created to represent =
the=20
pre-exising binary format.<BR><BR>I realize you may still disagree about =
the=20
degree to which the core of DIS 29500 is an attempt to represent a =
pre-existing=20
binary format but it would be more useful to know why you disagree? Yes, =
other=20
parts do exist and as I suggested in my comments and here, a properly =
defined=20
scope would at least put those in separate parts of one standard if not =
in=20
separate standards. (The question of a multi-part standard versus =
separate=20
standards is largely a matter of judgment and I have no real strong =
feelings on=20
that one way or the other.)<BR><BR>I don't think it advances the case =
for DIS=20
29500 to contend that it really has nothing to do with pre-existing =
binary=20
formats for office documents. If that were the case, then contradiction =
with=20
ISO/IEC 26300 is virtually assured. I can only go by what the documents =
actually=20
say and if you can find some part that denies what I have suggested is =
the case,=20
I would be really interested in seeing it.<BR><BR>*This isn't a question =
of pro=20
or con DIS 29500 but of understanding the<BR>scope(s) of its many parts =
and then=20
judging each one on it own. That is what scope enables us to=20
do.*<BR><BR>Properly scoped, we could separate out the parts (I assume =
you may=20
concede that some part of DIS 29500 is for representing pre-existing =
binary=20
formats) that are for representation of a pre-existing format =
and<BR>say: Well,=20
true they may disagree with or contradict other ISO standards but, since =
it is=20
the standardization of an XML representation of a pre-existing format =
and its=20
rules, ok.<BR><BR>Scope is what enables a sane discussion of *a* =
standard and it=20
relationships to other standards.<BR><BR>And properly scoped, it will =
also allow=20
us to evaluate what DIS 29500:<BR>Part 1: XML Representation =
Pre-Existing Binary=20
Format, has to say for itself.<BR><BR>For example, the syntax only =
conformance=20
clause. That is probably only necessary with&nbsp; this hypothetical =
part one=20
because it is probably unknown if not unknowable what semantics various=20
applications have applied to the pre-existing binary format.<BR><BR>A =
syntax=20
only conformance clause for Part X: DrawingML, would be very dumb. It is =
new=20
material and should have a clearly defined syntax and =
semantics.<BR><BR>Not to=20
mention that breaking DIS 29500 into properly scoped parts would make it =
a lot=20
easier to standardize while not impairing the ability of the various =
parts to=20
work together.<BR><BR>So, you can get OPC, which I think has a lot to =
offer=20
implementers but perhaps as a part of a multi-part standard, where each =
with its=20
own scope.<BR><BR>I really think you need to move away from the position =
that=20
DIS 29500 in anyway represents a useful model for a standard, however =
useful you=20
may think the various standards therein may be. There are ways of doing=20
multi-part standards where the parts are interdependent but =
concatenation isn't=20
one of them.<BR><BR>Another example: DrawingML (so far as I know) has no =

equivalent ISO standard with which to conflict. Great. But that should =
be a=20
separate question from whether any other part of DIS 29500 conflicts =
with some=20
ISO standard. The concatenation process used to formulate this standard =
prevents=20
that sort of granular evaluation, mostly because DIS 29500 represents =
several=20
related standards or parts of one standard in one rather large =
text.<BR><BR>I do=20
think we need to make more use of the mailing list, starting with Rob's =
comments=20
that are up for discussion next week, so that we can make effective use =
of our=20
time on the phone.<BR><BR>Hope you are having a great=20
day!<BR><BR>Patrick<BR><BR>PS: While I realize you probably still =
disagree about=20
the representation of a pre-existing binary format being one of the =
purposes of=20
DIS 29500, I am working on a general comment on contradiction that lays =
out the=20
foregoing with more precision and answer the question raised by other =
NBs on=20
contradiction. Not with the silly competing standards analysis of Ecma, =
which=20
makes no sense in a standards environment (how would you like to have =
competing=20
standards for house outlets?) , but on the basis of what is being =
standardized,=20
which is an entirely different=20
question.<BR></FONT><BR><BR></DIV></FONT></BODY></HTML>

--Boundary_(ID_J3i+eybRejbg2qpGXM38cw)--

