Hi Benoit,

One issue with this approach is that namespace binding is being performed 
before the DTD validator has an opportunity to add default attributes, 
some of which could be namespace declarations. The consequence of this is 
that some elements and attributes may be bound to the wrong namespace and 
for some others the namespace scanner may report a fatal error because the 
required namespace declaration comes from a default in the DTD.

Benoit Maisonny <[EMAIL PROTECTED]> wrote on 03/07/2005 12:31:18 PM:

> Hi,
> 
> I'd like to have a custom XNI parser configuration with the following 
> document pipeline:
> 
> NamespaceScanner -> XIncludeHandler -> DTDValidator -> SchemaValidator
> 
> Obviously, my point is to have xi:include elements resolved before DTD 
> validation so that I don't need to modify the DTD to recognise XInclude 
> elements.
> 
> I'm trying to do it by extending Xerces' XIncludeParserConfiguration: I 
> just override configurePipeline() where I switch XIncludeHandler with 
> DTDValidator (and similarly for the DTD pipeline, although I'm not sure 
> if it's really needed).
> 
> With this configuration, xi:include elements arrive at XIncludeHandler 
> without namespace URI. If I understand correctly, 
> XMLNSDocumentScannerImpl is binding namespaces itself only if there is 
> no DTD Validator. So, I set the scanner's DTDValidator to null. Am I 
> breaking anything with this?
> 
> Well, at least DTDValidator doesn't complain about undeclared xi:include 

> elements anymore. Next step is that I get SAXParseExceptions for IDREFs 
> pointing to inexistant IDs. It doesn't find those IDs because they are 
> in other "XIncluded" files.
> 
> It looks like XIncludeHandler is trying to validate the included files 
> separately with its own validating parser configuration. Is there a way 
> to avoid this? There's a big chance that an  "XIncluded" XML document is 

> invalid, generally speaking, since it's not meant to be complete.
> 
> I did read http://issues.apache.org/jira/browse/XERCESJ-1034 which is 
> related, but it doesn't explain why XIncludeHandler uses a validating 
> parser configuration.
> 
> Sorry if I miss something obvious, I dived into XNI only a few days ago, 

> and I can't swim just yet.
> 
> Thanks for your help,
> Benoit
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [EMAIL PROTECTED]
E-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to