Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 25508 invoked by uid 500); 6 May 2003 12:59:46 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 25412 invoked from network); 6 May 2003 12:59:45 -0000 Received: from w1309.hostcentric.net (66.40.78.254) by daedalus.apache.org with SMTP; 6 May 2003 12:59:45 -0000 Received: (qmail 18363 invoked by alias); 6 May 2003 12:59:43 -0000 Received: from unknown (HELO QUIET) (81.53.77.4) by 0 with SMTP; 6 May 2003 12:59:43 -0000 From: "Arnaud Le Hors" To: Cc: , Subject: RE: [ANN] XInclude processor for xml-commons Date: Tue, 6 May 2003 14:59:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > Well, if you want to go by the letter of the spec, which Joerg tells us > assumes validation to happen after XInclude processing This is not true. XInclude is defined to work with an infoset. How you get this first infoset and what you did with it (transformed, validated, etc.) before it is passed to the XInclude processor is totally open. It is true that the spec doesn't request XInclude processors to deal with extensions, such as those found in a PSVI. XInclude processors are only required to produce an infoset. So, you may waste your time validating before, if what you're interested in is extensions of the infoset that get dropped by the XInclude processor. But it's up to the user to decide. The bottom line is that there is no universal answer to the question of when XInclude should be processed. Different users may have different needs and answer it differently. Now, the main use of XInclude that we anticipate is basically to replace external entities references. In this case one is likely to want to process it fairly early on. Most likely before validation, especially XML Schema validation. So, from a Xerces point of view, we would want to support it by providing an XNI component that people can put in the parser pipeline typically, but not only, before the validator. Cocoon which looks at documents at a different level may want it at the SAX level. To end, I'll add a note on the debate over the "infoset-messing validation". Here again there is no universal solution. If all you are dealing with is XML documents - this is text -, validation merely means checking that your document validates against a set of constraints. You couldn't care less about any infoset augmentations in an environment where everything is text. On the other hand, if what you are dealing with is XML data - this is objects serialized in XML -, validation is the way you reconcile serialized objects with their real type. Infoset augmentations are then fundamental and can hardly be considered as messy... So, beware of over simplistic characterizations... :-) -- Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.