While attempting to fix the encoding problem Neil raised, I believe we
should also address a flow in the XNI with regards to namespace
resolution.

As it stands today xni.XMLEntityResolver notifies user about system and
public ids present in a DTD. During XML Schema resolution Xerces uses
entity resolver's system id parameter to pass location of a schema file
specified in the xsi:schemaLocation attributes. 

However, given that the "xsi" attributes are just hints, sometimes
documents don't have any location attributes and in this case it is
important to be able to pass the namespace URI via the entity resolver
to allow user to provide schema document. 
By definition the XML Schema's <import>s don't have to specify the
location attributes either, so this is yet another case when a namespace
should be passed to a user. 
Finally, some Xerces users have tables (similar to XML Catalog approach)
to map a namespace to a schema document. This table is used to overwrite
the original schema in the document. To know which schema document to
pick, they need to receive namespace of the root element in the
EntityResolver.

As it currently works in XNI, to access namespace user would need to get
XMLResourceIdentifier (via XMLEntityResolver callback), cast it to
xni.grammars.XMLGrammarDescription, query the type of Grammar and if the
Grammar represents XML Schema, cast it to
xni.grammars.XMLSchemaDescription to retrieve a namespace.

Given the importance of the XML Namespaces, this seems like an overkill.

Thus, I suggest we fix XNI instead.

The PROPOSAL
------------
Adding 2 new methods to the xni.XMLResourceIdentifier:

public void setNamespace(String namespace);
public String getNamespace();

I believe this is unlikely to break anyone, since I doubt that any of
our users actually provide their own implementation of
XMLResourceIdentifier.

Thank you,
-- 
Elena Litani / IBM Toronto

PS: Note that another solution could have been to specify that namespace
is passed as publicId in resolveEntity() method. Unfortunately, for
years users have relied on the publicId to be present only if there is a
DTD grammar, thus if we are to make such a change in Xerces behavior,
the risk of breaking someone is extremely big.

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

Reply via email to