You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Andy Clark <an...@apache.org> on 2000/10/10 19:02:22 UTC
[Xerces2] Xerces Native Interface (XNI)
If you've been following along in your song books, you'll
notice that we re-organized the Xerces packages for the
Xerces 2 concept implementation. This was done to separate
the core interfaces and classes from the implementation.
The core interfaces were moved to the org.apache.xerces.xni
package. Thanks to Ted Leung for using that name in a post
way back; when I read it, I said to myself, "That's a cool
name". So I'm using "XNI" for the Xerces Native Interface
which is the internal callback interfaces in the parser.
But the really cool thing about XNI is that it just defines
the information items available in an XML document and its
associated DTD. The source of these callbacks and what is
done with them is completely up to the implementation! Let
me give you some scenarios:
* The standard implementation is used to produce document
"events" from parsing an actual XML file; these events
are received by the SAXParser exposed through the SAX
handler methods. (This is the more boring scenario.)
* There is no XML file. Instead, a new document source
could be written to access a database and produce the
document events directly into the standard pipeline to
be exposed in any way.
* SAX and DOM aren't appropriate for the application. In
this situation, a new document handler can be attached
to the end of the pipeline to perform DB updates,
create JavaBeans, build a JDOM tree, or whatever your
heart desires.
Everything is possible by putting components together that
conform to the XNI interfaces. It just happens to be the
case that the DOMParser and SAXParser use the default
implementation that conforms to XNI; but this doesn't stop
you from creating other kinds of XML configurations.
I still need to write a lot more documentation on this but
the architecture overview[1] will give you the top level
description. In addition the design[2] document shows the
API available in XNI. But to help people truly understand
the interfaces, I added complete javadoc to all of the XNI
last night and checked the code into CVS. However, for
convenience I ran javadoc on the XNI package and attached
the ZIP file containing the docs to this message. Don't
worry: the ZIP is only 41K.
Please read over the design and let me know if you have
any comments or suggestions.
[1] http://www.apache.org/~andyc/xerces2/architecture.html
[2] http://www.apache.org/~andyc/xerces2/design.html
--
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org
RE: [Xerces2] Xerces Native Interface (XNI)
Posted by Ed Staub <es...@mediaone.net>.
>Anybody have suggestions for good UML diagramming tools?
Check out MagicDraw at www.nomagic.com (I think). $250, Java, very good
feature set, better UI and cheaper than Rose, better modeling (and owner)
than Visio, creates GIFs or SVG's. I asked them for a deal for Apache
developers several weeks ago, but heard nothing back. I've used it for
several weeks and still like it quite well. It's not perfect, but closer
than most!
ArgoUML, the best open source Java offering, doesn't support sequence
diagrams yet, darn it! And the collaboration diagrams are still very weak.
-Ed
-----Original Message-----
From: Andy Clark [mailto:andyc@apache.org]
Sent: Wednesday, October 11, 2000 5:54 PM
To: xerces-j-dev@xml.apache.org
Subject: Re: [Xerces2] Xerces Native Interface (XNI)
Ted Leung wrote:
> This looks good to me. Looks like all those hours on
> XPK4J paid off.
Yep! Pipelining the XML events makes the whole system very
simple and modular. I have some interesting things that I
want to do with the architecture: create scanners for other
document formats that emit XML-looking events in the XNI
system; create new kinds of grammars and validators like
Relax; parsers that create JavaBeans directly; etc.
> If you're planning to work on documentation, I think
> the next document that would be helpful would be
> something like a UML Sequence diagram.
Anybody have suggestions for good UML diagramming tools?
> I'm curious: In this architecture is it true that the parser
> is just a class that instantiates components and connects
> sources and handlers together? I'm hoping that the answer
> is yes.
Yes. :)
Check out the org.apache.xerces.parsers.XMLDocumentParser
class in CVS under the "xerces_j_2" branch. Aside from
no-op'ing the document and dtd handler callbacks (because
it's the last stage in the various pipelines), there's
little more to the code than just instantiating the
components; connecting the pipelines; and initializing
them.
Different parser instances that support various flavors
of APIs would just extend XMLDocumentParser, override
those methods of interest, and perform whatever operation
was needed. That's how we support SAX, DOM, and any other
API such as JDOM, etc.
--
Andy Clark * IBM, JTC - Silicon Valley * 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
Re: [Xerces2] Xerces Native Interface (XNI)
Posted by Andy Clark <an...@apache.org>.
Ted Leung wrote:
> This looks good to me. Looks like all those hours on
> XPK4J paid off.
Yep! Pipelining the XML events makes the whole system very
simple and modular. I have some interesting things that I
want to do with the architecture: create scanners for other
document formats that emit XML-looking events in the XNI
system; create new kinds of grammars and validators like
Relax; parsers that create JavaBeans directly; etc.
> If you're planning to work on documentation, I think
> the next document that would be helpful would be
> something like a UML Sequence diagram.
Anybody have suggestions for good UML diagramming tools?
> I'm curious: In this architecture is it true that the parser
> is just a class that instantiates components and connects
> sources and handlers together? I'm hoping that the answer
> is yes.
Yes. :)
Check out the org.apache.xerces.parsers.XMLDocumentParser
class in CVS under the "xerces_j_2" branch. Aside from
no-op'ing the document and dtd handler callbacks (because
it's the last stage in the various pipelines), there's
little more to the code than just instantiating the
components; connecting the pipelines; and initializing
them.
Different parser instances that support various flavors
of APIs would just extend XMLDocumentParser, override
those methods of interest, and perform whatever operation
was needed. That's how we support SAX, DOM, and any other
API such as JDOM, etc.
--
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org
Re: [Xerces2] Xerces Native Interface (XNI)
Posted by Ted Leung <tw...@sauria.com>.
This looks good to me. Looks like all those hours on
XPK4J paid off.
If you're planning to work on documentation, I think
the next document that would be helpful would be
something like a UML Sequence diagram.
I'm curious: In this architecture is it true that the parser
is just a class that instantiates components and connects
sources and handlers together? I'm hoping that the answer
is yes.
Ted
----- Original Message -----
From: "Andy Clark" <an...@apache.org>
To: "Xerces-J" <xe...@xml.apache.org>
Sent: Tuesday, October 10, 2000 10:02 AM
Subject: [Xerces2] Xerces Native Interface (XNI)
> If you've been following along in your song books, you'll
> notice that we re-organized the Xerces packages for the
> Xerces 2 concept implementation. This was done to separate
> the core interfaces and classes from the implementation.
>
> The core interfaces were moved to the org.apache.xerces.xni
> package. Thanks to Ted Leung for using that name in a post
> way back; when I read it, I said to myself, "That's a cool
> name". So I'm using "XNI" for the Xerces Native Interface
> which is the internal callback interfaces in the parser.
>
> But the really cool thing about XNI is that it just defines
> the information items available in an XML document and its
> associated DTD. The source of these callbacks and what is
> done with them is completely up to the implementation! Let
> me give you some scenarios:
>
> * The standard implementation is used to produce document
> "events" from parsing an actual XML file; these events
> are received by the SAXParser exposed through the SAX
> handler methods. (This is the more boring scenario.)
> * There is no XML file. Instead, a new document source
> could be written to access a database and produce the
> document events directly into the standard pipeline to
> be exposed in any way.
> * SAX and DOM aren't appropriate for the application. In
> this situation, a new document handler can be attached
> to the end of the pipeline to perform DB updates,
> create JavaBeans, build a JDOM tree, or whatever your
> heart desires.
>
> Everything is possible by putting components together that
> conform to the XNI interfaces. It just happens to be the
> case that the DOMParser and SAXParser use the default
> implementation that conforms to XNI; but this doesn't stop
> you from creating other kinds of XML configurations.
>
> I still need to write a lot more documentation on this but
> the architecture overview[1] will give you the top level
> description. In addition the design[2] document shows the
> API available in XNI. But to help people truly understand
> the interfaces, I added complete javadoc to all of the XNI
> last night and checked the code into CVS. However, for
> convenience I ran javadoc on the XNI package and attached
> the ZIP file containing the docs to this message. Don't
> worry: the ZIP is only 41K.
>
> Please read over the design and let me know if you have
> any comments or suggestions.
>
> [1] http://www.apache.org/~andyc/xerces2/architecture.html
> [2] http://www.apache.org/~andyc/xerces2/design.html
>
> --
> Andy Clark * IBM, JTC - Silicon Valley * 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