[
Lists Home |
Date Index |
Thread Index
]
I'd consider that farfetched except I recently
saw precisely that done. The programmer said,
"XML's just a string" and sent the customer a
rather complicated document for how his "XML string"
was to be prepared. Seems he didn't want to
bother with EBNF either. Problem is, his code
is now fielded because his managers didn't want
to take time to understand it either. If XML is
taken to mean a platform instead of syntax per
XML 1.0, the phrase from the Pete Seeger song,
"Neck deep in the big muddy when the old fool
said to push on" comes to mind.
Good DTDs aren't that hard to learn to read.
They can be expensive to create. That does
vary by project.
If a programmer can't read a DTD, I'd be inclined
to relieve him of responsibility for a project.
If a user has to read the DTD to use the software
correctly, I'd be inclined to relieve the programmer
of responsibility for a project. If either has only
view source as the means to figure out what is or
isn't a valid document, I'd feel inclined to
accept being relieved of a project.
What one tolerates varies by who the product is
intended to work with.
len
-----Original Message-----
From: Paul Prescod [mailto:paul@prescod.net]
But how would you feel about an XML parser implementor who
figured out how to implement XML only by
examining instances and not by reading the productions in the spec?
Surely you wouldn't accept that as an excuse for a broken XML parser or
WSDL parser in an expensive application server or database server: "Oh,
we didn't read the grammar/DTD."
That said, projects vary in their tolerance for misunderstanding.
|
