Consumers and Producers (was Re: Why I moved from Forbid to Literal)

At 02:37 PM 6/30/00 -0500, Paul Grosso wrote:
>I hear you, but suppose some Evil Generator Tool creates a document
>that does not comply to the "strict requirement" you want to put on it.
>Then what is my compliant consuming tool supposed to do?
>
>In my understanding, it is precisely the answer to that question that
>we are searching for.

That's the answer I'm looking for, certainly.

I'm much more concerned about how consumers of XML documents - parsers in
particular - should handle namespaces of various types than about how
producers should create them.

XML 1.0 describes processing from a consumer-centric viewpoint, not an
author-centric viewpoint, explaining XML in terms of the constraints and
grammar as interpreted by various types of processors.  Testing XML
documents is pretty easy if you have a conformant processor that provides
intelligible error messages.  (Yes, I know I'm dreaming.)

I'm much more comfortable describing what the behavior of the recipient of
a document should be, and leaving it to senders to figure out what
information to send those recipients.  If senders try to push junk to
recipients, recipients should be able to reject it, effectively restraining
what can be sent.

In that perspective, the specification defines what is acceptable to the
recipient; what the sender does is best practices.  I don't think that
constraining sender behavior for creating documents while leaving recipient
behavior for parsing those documents undefined is useful.  Once the
recipient has parsed the document, we have APIs to handle
parser-application interactions, but getting through the parser is important.

(Also, I've always found it disappointing that Namespaces in XML didn't
provide similar explanations of how to handle 'namespace errors' and how
those errors should interact with XML 1.0 errors.)

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
http://www.simonstl.com - XML essays and books

Received on Saturday, 1 July 2000 11:42:14 UTC