[
Lists Home |
Date Index |
Thread Index
]
Gustaf Liljegren wrote:
> ... We were
> many who disliked the first mentioning of XML 1.1, not so much for the new
> version number, but for the fact that so tiny changes was taken to justify
> a new version.
>
My first reaction is that I share the opinion of Gustaf and Mike Kay (among
others) who feel that XML 1.1 will only be worthwhile if it addresses more
of the known issues with XML 1.0. However, I've come to the conclusion that
this is inconsistent with the way that we all normally go about our
business. In software engineering, the perceived wisdom is to perform small
incremental changes, thereby reducing the overall risk of getting it wrong.
Why should the evolution of XML be any different? I have a little theory
for how this inconsistency came about.
<going long (sorry)>
It all started with the XML 1.0 declaration <?XML version="1.0"?>. This
signal, from the document to the XML processor, indicating what version of
the spec it adheres to, is the root of the problem.
I think it would be better if the XML processor worked out for itself
whether a document conforms - and the user of the document should indicate
to the processor what level of conformance he requires or expects. This is,
after all, just how we organize our program source code. We would have
similar problems in programming if we used such mechanisms to signal source
code compatibility. Imagine if Perl scripts like this:-
#!/usr/bin/perl5.1
or Java source code started with something like "using Java 1.0". The
result would be a strong reluctance to change, even if it was
backwards-compatible.
Programming languages are continually being refined. We, the users, are
generally pleased when the compiler vendor releases incremental changes (so
long as they are backwards compatible). We don't care if the changes mean
that a program that didn't compile last week starts to compile now, in fact
we are generally rather pleased! There is a corollary here to the XML 1.1
character issues: existing well-formed documents will continue to be
well-formed and some badly formed documents under XML 1.0 will no longer be
so. If there are changes required to XML that are not backwards compatible
(namespaces), then it should be up to the document recipient to signal to
the processor what kind of documents she will accept.
Another problematic area where XML documents signal their content to the XML
processor is the DTD declaration. This problem has been recognised with XML
Schemas, moving the responsibility to the receiver of the document to decide
what schema the document should conform to. I think this is another facet
of the same issue.
If we get rid of the XML declaration, we avoid a problem noted by Elliotte
Rusty Harold some time ago during the blueberry debate, whereby document
editors will feel inclined to mark their documents with the latest version,
whether or not they contain mark-up features requiring that version. It
also avoids an associated problem of knowing in advance what document
version you are going to create in a streaming environment.
<conclusion>
Get rid of the XML declaration and we can all be a lot more relaxed about
making small, incremental changes to the XML specifications. Does anyone
agree, or should I get my flame-proof underwear on?
Kind regards
Rob Lugt
ElCel Technology
http://www.elcel.com/
|
