RE: [xtm-wg] Status of Core Deliverables document

["Kal Ahmed" <kal@ontopia.net>]

Murray Altheim wrote:
> Kal Ahmed wrote:
> >
> > > [steve pepper]
> > > > A number of the comments on the Review Specification urge (minor)
> > > > changes to the DTD which is also contained in the Core
> Specification,
> > > > so we really need to know at an early date whether the DTD is now
> > > > cast in stone or not.
> > > >
> > > > Could the editors, and others, please make their position known?
> > >
> > > Well, "never say never" -- so I'm uncomfortable with "cast in stone."
> > > But my view is that the bar for changes should be set almost
> > > prohibitively high.
> > >
> > > I would also like some consideration to be given to versioning issues
> > > for the DTD, so that we can have discussions that include the
> idea that
> > > a change might not be possible for 1.0 but would be possible and
> > > beneficial in 2.0 (for example).
> > >
> >
> > Why put off till later what can be fixed now ? If there is
> general consensus
> > (and that is a big if) that something is wrong, what possible benefit is
> > there in forcing users to wait till the next DTD upgrade, and
> so allowing
> > the buildup of 'legacy' 1.0 XTM documents ? If something is
> wrong, fix it
> > now.
>
> As Sam stated, unless there is an outright error in the current
> XTM 1.0 DTD,
> I agree entirely that it should be considered fixed. The *point* of fixing
> the DTD is to allow XTM-based technologies to begin to be developed. If
> the DTD is not solid and undergoes further changes, two things happen:
>
>   1. there is no perceived stability to the core of the specification,
>      and nobody will dare spend development time on a moving target. I
>      usually call this the "Microsoft-syndrome," but it's a big problem
>      in the software industry in general.
>

There is no point having something that is stable and wrong. And especially
not if vendors then
try and fix the 'problems' that they perceive in proprietary ways. We will
have XTM <BLINK> tags and
lose as much if not more market than if we had bitten the bullet early on.

And anyway I thought the Microsoft syndrome was to use the first release of
a product and then find out just how horribly buggy it is and have to wait
12 months and pay $300 for the "upgrade" to the next version.

> Many "core" technologies have suffered from instability. HTML
> comes to mind.
> RDF is stable, and even with its known problems has garnered
> enormous industry
> support, such that other technologies have been based on it. My
> belief is that
> the greater the stability, the wider the support, even with minor
> problems.
> Look at IP.
>

And look at the mess the 640K limit caused to certain Intel-based operating
systems, or the stable, widely accepted two-digit-year date convention.
Sometimes you have to bite the bullet and do it early all or else later on
you'll be paying for teams of retired COBOL programmers to come out and
convert your terabytes of XTM 1.0 to XTM 2.0.

>   2. any investment already being made in the current XTM 1.0
>      specification will be lost. And if not lost, we court turning away
>      those who might consider investing.
>

How much investment do you think the time between XTM 1.0's debut in
Washington and now do you think there has been ? If all of this year's
investment has happened in the last two weeks, I guess I'm going to get
fired. Seriously, the real investment is going to start over the next few
months, so lets build that investment on a rock solid DTD.


> We promised to deliver a specific set of deliverables in Dallas, and we
> delivered on that promise. We held open the editorial process five days
> longer than we originally had expected, and did not receive feedback on
> some of the issues that have now been reopened in discussions here. I
> note that these discussions have yet to settle into a single answer, even
> among those promulgating the changes. Everyone has their opinions on what
> should or should be XTM, and the opinions themselves evolve too. We as a

> group can continue to churn on this forever (as anyone who has done
> standards work would agree), but at some point one delivers a version 1.0.
> We have done that. What remains to be done in Paris is very clear to me,
> and that does not include further modifications of the XTM DTD. There are
> always possible "improvements" (in 2.0) but at this point any changes to
> the core would only be damaging to the further success of XTM. The core
> of the spec is finished, now we must finish documenting what it is we
> have, warts and all.
>

No, we must discuss and fix any problems we agree on and then document.
Otherwise we really do
stray into Microsoft territory.

> [I just now have read Michel's message on this topic, and send this in
> agreement with him. Stability of the DTD in order to promote development
> should be our primary objective.]
>
> In final note, I have spent the last three or four weeks working with
> the Cycorp Upper Ontology, transforming it into XTM syntax. I have not
> noted any particular problem with the current DTD in representing the
> various aspects of the ontology. I also note that Nikita has been
> successful in creating a variety of XSLT transformations from the
> existing ISO 13250-compatible DTDs into XTM. I think this should be
> adequate demonstration that we're on track.
>

I have no argument with the XML construct known as the DTD - its a truely
masterful piece of work (Aside: this is praise from a man who can never
remember the correct syntax for a CDATA section :-), nor do I have any
issues with the structure of the documentation (though I have some quibbles
re: the content). However I would much rather that we have a syntactically
correct, well documented DTD which we all agree really is the best 1.0
release we can put out.

I wouldn't even mind calling it 1.1

Cheers,

Kal


To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com