From owner-incits-v1@incits-v1.org Wed Jul 11 19:47:08 2007
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Date: Wed, 11 Jul 2007 22:45:32 -0400
From: Rex Jaeschke <rex@RexJaeschke.com>
Subject: RE: INCITS-V1: Progressing DIS 29500
In-reply-to: <4695685F.4090805@durusau.net>
Sender: owner-incits-v1@incits-v1.org
To: incits-v1@incits-v1.org
Reply-to: incits-v1@incits-v1.org
Organization: C#, VB, .NET, C, C++, Java Seminars and Consulting
Content-language: en-us
Thread-index: AcfEE9bENUa5Ne/MTomomZ1gcQxC7QAGAP3A
X-PMX-Version: 5.2.0.264296

I have a number of comments, all of which I think are in harmony with
Patrick's suggestions:

1. TC45 really appreciates all the feedback coming from the U.S. and other
NBs, and thinks that the final resolutions to a great many of the comments
seen thus far will significantly improve the spec.

2. The current plan as I have presented it to TC45 is that once the ballot
has closed, TC45 will start work on reviewing all the comments and proposed
responses. I expect that every few weeks, TC45 will update a public website
with its status on comments reviewed thus far. The idea here is to let all
NBs to be able to see TC45's responses to their comments, and to be able to
have a direct dialog with TC45 on further refining the final version of
responses. This process would be continued up to the BRM.

3. The technical agendas of recent meetings of TC45 have been dominated with
discussions of some of the comments that have been reported at NB meetings.
For example, at the most recent TC45 meeting, we spent all the technical
time discussing the idea of turning the spec into a true multi-part
standard. And that discussion came as a direct result of the previous V1
meeting. So, TC45 is listening and reacting positively.

4. Yesterday, as TC45 liaison to SC34, I sent to Ken Holman a draft proposal
for the establishment of a Joint Maintenance Group per the Directives, to
handle defect reports and future revisions. He plans on including this
document in the next SC34 mailing that he'll prepare this coming weekend. I
requested agenda time at the Dec SC34 plenary to discuss this topic.

Rex

----------------
Rex Jaeschke      www.RexJaeschke.com   Skype: RexJaeschke
2051 Swans Neck Way, Reston, VA, 20191-4023, USA
Phone: +1 703 860-0091, Fax: +1 703 860-3008

> -----Original Message-----
> From: owner-incits-v1@incits-v1.org [mailto:owner-incits-v1@incits-
> v1.org] On Behalf Of Patrick Durusau
> Sent: Wednesday, July 11, 2007 7:32 PM
> To: Incits-V1
> Subject: INCITS-V1: Progressing DIS 29500
> 
> Greetings!
> 
> With my chair hat firmly on the table I wanted to make some comments
> about defining "progressing DIS 29500" as I understand it.
> 
> In my view, "progressing DIS 29500" means that the text approved as an
> IS has a variety of substantive technical errors (excepting editorial
> errors that can't be reached within a reasonable time period) corrected.
> 
> How would we get to that state?
> 
> Well, we know that the ballot closes in early September and it is
> unlikely that any ballot resolution meeting is going to be scheduled
> before the end of the year. While I greatly enjoy the company of each
> and every one of you, I don't really relish the idea of spending the
> Christmas holidays in a ballot resolution meeting.
> 
> So, how would we spend those four months or more months? We could simply
> watch the drive-by bloggings on the comments, which will by that point
> be public.
> 
> Or, we, along with TC 45 and other NBs around the world, who represent
> some of the finest minds in markup languages, could turn our attention
> to devising solutions to issues in DIS 29500 so that the text proposed
> in response to comments at a BRM fixes the technical issues in the
> current proposal.
> 
> That is to say that largely on the same timetable that exists for DIS
> 29500 "as written" that a truly collaborative effort could result is a
> DIS 29500 "as corrected" which would be to the benefit of all concerned.
> 
> Granted it is going to take a lot of effort, which the members of TC 45
> have already contributed to get to this point, but I see the
> alternatives as follows:
> 
> DIS 29500 "as written"
> 
> DIS 29500 "as corrected"
> 
> emerging at approximately the same time.
> 
> To my mind, the second is more deserving of the phrase "progressing DIS
> 29500" than the former.
> 
> Lest you think I am being overly optimistic, recall that Tom Ngo said in
> Washington that TC 45 has already discussed the possibility of
> refactoring DIS 29500 into "parts" as the term is used in ISO. And I
> don't think any of us want to see an ISO standard that doesn't properly
> define XML Schema datatypes or fails to properly define any number of
> other easily corrected items before it issues as an IS.
> 
> I think the key to making that sort of progress is a general recognition
> of the hard work that TC 45 has done already and a reciprocal
> recognition by TC 45 that suggestions for corrections are well
> intentioned and meant to make DIS 29500 a better proposal and not to
> delay or impede its progress.
> 
> I am not so unaware of the by play surrounding DIS 29500 to think for a
> moment that this is purely a technical issue. However, I do think this
> is a case where the hard core technical people can blunt the political
> and other agendas of others by banding together to make DIS 29500 the
> best possible proposal (that is with corrections) before it becomes an
> IS.
> 
> I am currently an editor of four or five standards in at least three
> different fields and have no illusion that any version of DIS 29500 is
> going to be completely problem free. If it were, then we would be
> putting our committees out of business. ;-) Seriously, no standard is
> perfect but that is no excuse for pushing a proposal that has admitted
> correctable problems forward without first correcting the technical
> issues as best we can.
> 
> Let me give you an example of an error that could go uncorrected in the
> corrected version of DIS 29500. Take my comment on element names. I
> really think that is a problem but it is an aesthetic one. Granted once
> it becomes an IS we are going to be stuck with inconsistent naming
> conventions but (hopefully) most users are never going to see that sort
> of thing anyway.
> 
> On the other hand, not having meaningful conformance clauses for a
> refactored DIS 29500 prevents the goal of interoperability that is one
> of the primary goals of ISO standards. How is my DrawingML application
> to distinguish itself from any one of hundreds if not thousands of other
> DIS 29500 applications, all of which claim to conform to DIS 29500? The
> answer is as written it can't. Nor can I guarantee that it will
> interoperate with other DrawingML applications.
> 
> I don't mean to suggest that my personal views of those two issues (or
> any others that I have mentioned) will actually prevail but I had to use
> examples that were relevant to the proposal in front of us.
> 
> I am willing to work within V1, with TC 45 members, TC 45 itself, or
> anyone else, with a view of producing a corrected DIS 29500 largely on
> the same schedule as it would face in any event.
> 
> How about you?
> 
> I hope everyone is having a great day!
> 
> Patrick
> 
> PS: A quick story to illustrate my point about cooperation:
> 
> Two friends were riding through an ancient battle field between two
> countries. The first one asked his friend who was from one of the
> warring countries, "Why?" To which the second friend replied: "At first
> we fought for glory and honor. Then we fought for revenge for fallen
> friends and loved ones. Finally, we fought because we had forgotten how
> to stop."
> 
> I think it is time to remember how to stop fighting and to start
> cooperating.
> 
> --
> Patrick Durusau
> patrick@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Acting Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
> Co-Editor, OpenDocument Format (OASIS, ISO/IEC 26300)
> 




