[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Rich Salz [mailto:rsalz@datapower.com]
>
> > prestigious one) graduate students did not write a C compiler as
part of
> > their compiler course, much less undergraduates. They wrote a
compiler
> > for a stripped down language that looked like C but wasn't because
all
> > the difficult bits had been pulled out. I don't want to see a lot of
de
> > facto XML subsets in every other program. Making a parser simple
enough
> > that a lot of people *think* they can write one quickly is asking
for
> > trouble.
>
> My point exactly.
My experience is that XML is already largely there. I regularly invest
a good amount of effort into explaining to people that XML is actually a
good bit more complicated than they thought, and that they really are
better off using standard parsers.
No amount of clarifying the spec is likely to dissuade people from
thinking they can do better. I do think there is real value in
attempting to simplify XML to the point that the type of people who are
inclined to roll-their-own, get it right. As others have implied,
simplifying it to that extent will likely lessen XML's usefulness to in
significant set of significant, existing scenarios. So long as those
customers are satisfied with XML 1.0, why does that matter?
Maybe calling it XML 2.0 is part of the problem. Instead, we should be
asking, are there a decent set of current/future XML customers who would
significantly benefit from a simplified XML profile? SOAP has already
done this, in that it disallows DTDs (and PIs?). I'm far more
interested in the question of what would we build for XML-simplified,
than I am interested in XML 2.0. Calling something 2.0 typically
implies that it subsumes everything in 1.0. Many of the goals that
people have been discussing on this thread are directly contrary with
that implication.
-derek
|
