OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Options in XML 1.0

[ Lists Home | Date Index | Thread Index ]
  • From: Jonathan Borden <jborden@mediaone.net>
  • To: "Simon St.Laurent" <simonstl@simonstl.com>, xml-dev@lists.xml.org
  • Date: Fri, 10 Nov 2000 15:24:45 -0500

Simon St.Laurent wrote:

> At 01:40 PM 11/10/00 -0500, Jonathan Borden wrote:
> >    Questioning wisdom is easy to do unless you propose an alternative.
> >term "armchair quarterback" comes to mind. I'm willing to listen to
> >fixes to the true problem you are discussing (wasn't this the crux of the
> >"Between Raw and Cooked" thread?) But, if your proposed fix trashes my
> >current and planned implementations I am going to either loudly complain,
> >mandate XML 1.0 (i.e. not accept your solution), or both.
> I proposed re-examining the categories of processing XML 1.0 defines to
> examine whether those categories really work.  I don't think they do, but
> don't think an obvious solution leaps out.  Reaching solutions is
> difficult, and starting discussions with a particular solution doesn't
> like a smart way to proceed when it's not even clear to many people that
> the problem exists.
> I've been working at this in various forms (XPDL, Common XML, several
> chapters in books) for years, and I'd really prefer that you leave phrases
> like "armchair quarterback" at home.

    I'm sorry you couldn't see my VBG while writing that ... I owe you a
beer next week.

> You're quite welcome to mandate XML 1.0 for your own projects.  I'm sure
> the W3C would be disappointed if you opted to ignore Namespaces and W3C
> Schemas, not to mention a few of their other specs, but it's certainly up
> to you as implementation designer.

As it turns out I'm in the middle of writing a particular specification
which employs PEs to get around problems with DTDs and Namespaces, (see
Modularization in XHTML for a great example of why this is needed). Perhaps
XML Schemas will solve this problem, but my application needs to work today
using current and widely deployed software. Microsoft (as an example) has
had enough trouble distributing the XSLT module of IE5, despite the fact
that the XSLT REC came out a year ago. I wonder how long it will take for
IE5 to contain a conformant XML Schema validator? Or Apache etc. etc. And
then how long will it take to get this software in place on say 90% of
working sites. For example even though Java 1.2 has been out for awhile and
Servlet 2.2 has been out for awhile and 2.3 is on its way, the openhealth
ISP still runs Servlet 2.1 and so our code needs to be dumbed down.

So, in the interest of code that can be used today, I want solutions that
can be implemented today, using today's XML. But I respect your desire to
discuss the future. But in the context of the future, I want my apparently
'legacy' code to continue to work. I don't want to rearchitect my system
every year, nor recode every year. I thought that promise of XML was that my
documents would last 100 years. So if you suggest that only certain of these
documents will last I get twitchy.

> >    That being said I would no more wish to require someone to use a DTD
> >than I would wish to require someone to use an XML Schema, and part of
> >wisdom of XML 1.0 is that it requires neither. I'm not so worried that
> >Common XML wishes not to use DTDs as I am that future incarnations of W3C
> >XML attempt to deprecate DTDs over XML Schemas.
> That's a problem which goes well beyond anything I was discussing.  I'd
> prefer an XML which made it easy for document creators to use DTDs _or_
> Schemas _or_ neither by _their_ choice, not the parser creator, but I
> think that's necessarily incompatible with your hopes.

We agree in this preference.

Jonathan Borden
The Open Healthcare Group


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS