xml-dev - Re: What Clean Specs Achieve

[roddey@us.ibm.com]

>>>
>>>But is anyone here trying to _implement_ Java?  Lots of folks here are
>>>indeed trying to _implement_ XML 1.0 (parsers and SAX), XLink and
XPointer,
>>>Namespaces, XSL, etc.  It's not like we're only trying to _use_ them, as
is
>>>the case with Java (or SQL, another example that's been bounced around.)
>>
>>Most of them seem to be succeeding.  What should we conclude? -Tim
>
>Most people who don't succeed, don't announce.  We can't conclude
anything.
>
>Judging from the volume of questions (and controversy) on this and its
>sibling lists (XSL-list, xlxp-dev), there's a lot of improvement that
could
>be made.


As an above average developer, who just implemented the bulk of his first
XML parser (C++) in a binge over the last month, I have to question whether
any 'average' developer will ever implement a full featured parser. I found
it very non-trivial to write an XML parser that was well decomposed and
layered and pluggable, while retaining competitive performance. I found
that XML itself was not very conducive to fast processing and reasonably
simple architecture.

As to the spec... I don't mean to hurt anyone's feelings, but I found the
spec during that effort to be as confusing as enlightening. It describes
the logical (sometimes illogical :-) design of XML. But it doesn't help so
much when it comes to trying to apply that to some physical design. Of
course that's not their job, but obviously there have been a good number of
parsers written and some obvious issues in implementation could be
discussed, to save implementers from doing the same things over and over
again and then having to fix them. Of course now its all obvious :-) But I
had to really struggle through it the first time. A 4 or 5 page prose
document describing the most obviously implementation pitfalls (and
possibly some obvious implementation strategies) could have saved me a week
probably. Yes the spec is supposed to describe XML, but is its overall goal
not to facilite the development of software that implements it?

And I suspect that perhaps there are probably parsers out there, where the
developers really cannot intellectually prove that they do the right thing.
I would be willing to bet that some of them just fix problems until it runs
the James Clark tests and digest the Bosak files? When a customer reports a
problem, and sends in a sample file, then they look at the spec and try to
see if that file seems to correspend to the spec and fix their code to
handle if so. That is far easier than trying to prove that every method in
your code meets the spec (though its obviously not the optimum thing to
do.)

Am I being too cynical here? Maybe so. But, I just don't think that an
'average' developer could write an XML processor that is complete,
expandable, maintainable, and speedy, if all he/she had to work with was
the raw XML spec (at least not in a time that would be acceptable in a
commercial setting, which is what mostly counts I guess?) I think that it
would more likely just be 'proven' to be correct through empirical testing,
not through an ability to completely understand all the interactions
expressed in the XML spec and implement them cleanly.

Also, the interactions that just exist in XML (regardless of how well or
badly they are expressed in the spec) means that the skill level required
to do something that is *maintainable and expandable* (i.e. well decomposed
despite all the interactions) is that higher still. Arguing whether or not
someone could manage to read the spec and squeeze something out that (in
whatever shape) was a fully compliant parser, isn't very meaningful to me.

Oh well, that's my po' two cents worth. I think that yes you need a dry
laying out of the facts *and* some guidance at a higher level, related as
much to possible implementation issues as interpretation issues. I think
that the current spec perhaps is somewhere in between the two and thus
somewhat fails to fully please either master?



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)