- From: Simon St.Laurent <simonstl@simonstl.com>
- Date: Sat, 01 Jul 2000 11:44:48 -0400
- To: <XML-uri@w3.org>
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