[jdom-interest] Issues with the EntityRef implementation

[Brett McLaughlin]

Can you try with Xerces 1.3? If that solves this problem, it would be a good
impetus to upgrade to that version in CVS. What's the exception you get on
setting the feature? Looks like we need to track that down...

-Brett
----- Original Message -----
From: <philip.nelson at omniresources.com>
To: <jdom-interest at jdom.org>
Cc: <jhunter at acm.org>
Sent: Tuesday, May 01, 2001 3:46 PM
Subject: [jdom-interest] Issues with the EntityRef implementation


> Well, first the good news!
>
> As we planned it at the SDWest BOF, I started implementing the EntityRef
> class.  The first part is done.  This means that entities are always
> expanded and there is no trace of the original entity in the document.
This
> works correctly with internal, external entities and dtds and with Xerces
> 1.2 and JAXP/Crimson.  So far so good.
>
> I added a method to SAXBuilder called setExpandEntities(boolean expand).
> This method will allow you to turn off entity expansion (with a false).
In
> this case, we tell SAX not to expand entities and instead insert EntityRef
> instances in the content where the entity occurred.  This EntityRef is
> simple in that is has only the name, publicID, systemID attributes along
> with the usual JDOM things like clone, serializable, getParent,
getDocument.
> From the point of view of the api, this also works as expected, putting
> &entityName; in your output as expected.
>
> The problem is in SAXBuilder.  While both Xerces 1.2 and Crimson return a
> value (true) for the feature
> http://xml.org/sax/features/external-general-entities, they both throw an
> exception if you try to set the feature.  Since this is part of the SAX
2.0,
> we should assume that at some point the parsers will support the feature.
I
> haven't tried Xerces 1.3 yet but it may be supported there already.
>
> It seems that I can
> - wait until the parsers support the feature to implement no expansions in
> SAXBuilder
> - work around the issue by passing the expand flag to the handler and
> manually building the EntityRefs from the elsewhere in the sax api.
>
> If we think that SAX 2.0 compliance is just around the corner, I would say
> wait since it will likely be more standard behaviour across parsers.  Both
> options should be doable.
>
> The next thing in this path is to build a content string in DocType for
the
> internal dtd subset.  Shouldn't be too hard and I think that may be useful
> to people now.  Or not...
>
> In DOMBuilder, a separate but related issue prevents me from expanding the
> entities at all but that is not new so I won't do much about it until the
> SAX issue is handled.  For now, DOMBuilder will put EntityRefs when it
> encounters entities (but without public or system ids like now).  The
issue
> is that since we don't build from a file, we don't actually have much
> control over what we get.  Features are far less standard anyway.  Here, I
> think going to the Document for the internal subset makes more sense and
> this is pretty easy from my 10 minute glance.  Again, I need to pass a
flag
> to the builder to indicate what to do.
>
>
> Jason, since there are a lot of changes, I'll send the source to you or
> anyone who explicitly asks for it and is willing to do a little testing.
I
> attached a file listing the changed classes and hopefully all the methods.
>
>