Re: [Xerces2] Separating XNI Core from Parser Config

[Ted Leung <tw...@sauria.com>]

+1 on factoring configurations out of XNI.

As far as DTD handler discussions, I thought we were basically
going around in a circle because of some people's paranoid fear
of going slower ;-)

Ted
----- Original Message ----- 
From: "Andy Clark" <an...@apache.org>
To: <xe...@xml.apache.org>
Sent: Friday, March 23, 2001 6:20 PM
Subject: [Xerces2] Separating XNI Core from Parser Config


> I'm working on enacting a separation of what we've been talking
> about as the core of XNI with other extensions that we have and
> will add in the future. The first such extension is the parser
> configuration stuff that Arnaud has been talking about in a
> previous thread titled "[Xerces2] Processing Models, ...".
> 
> So far I have defined a set of parser configuration interfaces
> and added them to the .parser sub-package from the main XNI
> package. These interfaces are a combination of interfaces that
> (will be) moved out of the main XNI package as well as defining
> a new interface based on Arnaud's ParserConfiguration experiment.
> To look at these changes, do a CVS update on the xerces_j_2 with 
> the -d option to pick up the new directory.
> 
> The reason I made this change was to separate anything not 
> core to XNI's "streaming information set" interfaces because 
> the .xni package became a dumping ground for everything. Ugh!
> So now I've moved the parser configuration stuff to a separate
> package.
> 
> The work that still needs to be done, though, is to actually
> implement this change in the Xerces2 set of parsers and then
> remove the old interfaces to clean up the .xni package. In the 
> end we should be left with the following setup:
> 
>   package org.apache.xerces.xni
>     class QName
>     interface XMLAttributes
>     interface XMLDocumentHandler
>     interface XMLDTDHandler *
>     interface XMLDTDContentModelHandler *
>     class XMLString
>     interface NamespaceContext **
>     interface XMLDocumentFragmentHandler **
>     package parser
>       interface XMLComponent
>       interface XMLComponentManager
>       interface XMLParserConfiguration
> 
>    * These two interfaces will probably be combined into a single
>      interface per the DTD handler discussions we've still yet to
>      finalize. Can we do this soon? What were people's thoughts
>      on my proposal?
> 
>   ** These two interfaces are currently included because I think
>      it's a good thing to define document fragments in general
>      even if we currently don't implement anything that uses
>      them. Although, it was my intention to use these interfaces
>      in the implementation of the XPath matching code used for
>      supporting XML Schema identity constraints.
> 
> I think this setup is cleaner and will allow us a much better
> mechanism to expand XNI in the future.
> 
> Thoughts?
> 
> -- 
> Andy Clark * IBM, TRL - Japan * 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
> 


---------------------------------------------------------------------
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] Separating XNI Core from Parser Config

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

Ted Leung wrote:
> As far as DTD handler discussions, I thought we were basically
> going around in a circle because of some people's paranoid fear
> of going slower ;-)

Yeah, I think so, too. But the problem with the old interfaces 
is that they are arranged in such a way that it's impossible to
get useful parameter entity reference boundaries. In order to
make this information available, the interfaces need to be
expanded and it's very easy to go overboard. 

Making those extra calls *does* take time. However, people that
need transactions/second in a server environment shouldn't be
processing the DTD all of the time anyway. They would be using
cached grammars so the time spent to process the DTD is not a
big concern. And the applications that need this information 
usually operate in user-time.

I'll be taking some vacation soon but perhaps I can finish
spec'ing out the new DTD handler interface before I leave. I'll
see if I have time.

-- 
Andy Clark * IBM, TRL - Japan * 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