OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SAX-ext Attribute + Entity Parsing

Eric van der Vlist wrote:

> Instead of adding methods to the SAX2 classes, have you considered using
> the existing ones to pass additional elements/attributes from a specific
> namespace to the applications using the existing ones ?

> The applications would then see this as an element:
> <xxx:attributeDecl name="..." type="..." defValue="..." value="..."/>

My problem here is that I have no control over the DTD spec. It would be
nice if I could do that, but it is far from my hands. I'm just paid to
implement the code :) 

Of course the other problem is that even in the output XML file, we
can't guarantee that the authoring tools will adhere to this format.
It's hard enough getting the likes of Autodesk and Microstation to
export decent content as is, without asking for these extra tidbits.

The X3D spec is a hideously complex bit of XML which is making life all
the more complicated. Basically they are using Parameter Entities in a
form of strong typing for the attributes (their ideal is to use schemas,
but it too is lacking currently for what they want/need) and then
expecting to be able to have nice DOM transmutation to custom API's if
and when needed. Nice from the content authoring perspective, hideous
from a browser builders...

The end result is that as I'm parsing the attribute declaration, I would
like to build type information from being able to match the info passed
through attributeDecl and one of the earlier calls to
LexicalHandler.startEntity() and DeclHandler.internalEntityDecl().
Currently, because the attributeDecl is returning me the fully expanded
parameter entity (as per specification), but it leaves me with a bit of
a mis-match. (I'd like to use the parameter entity def for other
internal data/document building purposes). Is there another way using
the existing SAX2 APIs to get this information assuming that I have no
control over the DTD/Schema being passed?
> The main benefit from this method is that the additional information
> gathered from your documents are passed to the applications using a
> common and "standard" API and that you don't need to modify the layer
> between these applications and the SAX parser to get them.

Could you explain a little more what you mean by the layer modification
bit? Apart from supplying my own custom *Handler implementations, as per
the SAX2 spec, I'm not currently getting any lower into a specific SAX
parser implementation. 

Justin Couch                                    Author, Java Hacker
http://www.vlc.com.au/~justin/               Java 3D FAQ Maintainer
http://www.j3d.org/              J3D.org The Java 3D Community Site
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
                                              - Greg Bear, Slant