XNI: add XMLResourceIdentifier to startExternalSubset()

[Elena Litani <el...@ca.ibm.com>]

Hi all, 

I would like to propose to modify  startExternalSubset() method in
XMLDTDHandler to include XMLResourceIdentifier:
public void startExternalSubset(XMLResourceIdentifier identifier,
Augmentations augmentations) 

The method startDTD() already includes a resource identifier, however,
if an internal subset is present, the identifier will include
information about the document entity -- not the external entity [DTD]. 
I think that XNI behaves correctly in the described case - it provides
the base URI for all internal declarations.
However it also means that XNI does not provide the baseURI for the
declarations that came from external DTD subset.

I found out about it when started to implement DOM Level 3 baseURI [1].
Per DOM Level 3 baseURI for entities corresponds to [declaration base
URI] in the XML Infoset.

Comments? 

[1]
http://www.w3.org/TR/2002/WD-DOM-Level-3-Core-20020409/core.html#Node3-baseURI

-- 
Elena Litani / IBM Toronto

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Re: XNI: add XMLResourceIdentifier to startExternalSubset()

[Andy Clark <an...@apache.org>]

Elena Litani wrote:
> I would like to propose to modify  startExternalSubset() method in
> XMLDTDHandler to include XMLResourceIdentifier:
> public void startExternalSubset(XMLResourceIdentifier identifier,
> Augmentations augmentations)

I read your arguments, looked at the spec, inspected the code, 
and completely agree with you. (How often does *that* happen? 
Probably less than Haley's Comet... ;) I fully support the
recommended change.

I would just warn you that a "build clean" may not properly 
find the files that implement this interface. There are some 
cases where the location of the missing method (I say 
"missing" because the prototype has changed) is not apparent. 

For example, any class that that implements the interface
but is abstract may cause subclasses to fail but the real
cause of the problem is the base class. For example, the
abstract parsers frequently caused this problem when I was
updating the codebase to conform to changes we decided when
developing XNI.

In short, fix the method in the correct place -- don't just
add the method in a class because the compiler complained.
It may even be best to just do a global search for the
string "startExternalSubset" to make the mods. (Also fix
the Javadoc while you're at it.)

Thanks!

-- 
Andy Clark * andyc@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org