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 2001/07/03 08:42:53 UTC
[Xerces2] Design Decisions (LONG)
This list is eerily quiet these days in regards to Xerces2
design and development. Hmmm... Well, I'm going to raise a
few more design points and then make some unilateral
decisions unless there's some discussion or objections.
[1] DTD Handler Interfaces
We've had some discussion but no resolution on what is to
become of the XMLDTDHandler and XMLDTDContentModelHandler
interfaces. Obviously the right balance of information and
usefulness is beyond our reach.
I'm now leaning towards Glenn's earlier suggestion that we
can provide DTD information needed to DTD editor writers
(arguably a very small percentage of the parser user base)
via the SAX xml-string property. I'm not suggesting that
we *will* implement this before rolling out Xerces2, merely
that we *can* support communicating more information in
the future through this (or a similar) mechanism.
I'm still torn between 1 and 2 interfaces so I'm gonna
stay with 2 separate interfaces. However, I would make
the following changes to the XMLDTDContentModelHandler
interface, in an attempt to provide a better callback
interleaving with start/endEntity.
public interface XMLDTDContentModelHandler {
public static final short OCCURS_ZERO_OR_MORE = 0;
public static final short OCCURS_ZERO_OR_ONE = 1;
public static final short OCCURS_ONE_OR_MORE = 2;
public static final short SEPARATOR_CHOICE = 3;
public static final short SEPARATOR_SEQUENCE = 4;
public void startContentModel(String elementName) // *
throws XNIException;
public void any() throws XNIException; // +
public void empty() throws XNIException; // +
public void startGroup() throws XNIException; // rename
public void pcdata() throws XNIException; // +
public void element(String name) throws XNIException; // rename
public void occurs(short occurs) throws XNIException; // rename
public void separator(short separator) throws XNIException; //
rename
public void endGroup() throws XNIException; // rename
public void endContentModel() throws XNIException;
} // interface XMLDTDContentModelHandler
[2] Pass Base URI to startEntity Callback
In the continuing effort to pass as much information via
XNI as possible, I would suggest passing the base systemId
when calling the startEntity method in all of the handlers
that define this method.
Therefore, the method would have the following prototype:
public void startEntity(String name,
String publicId, String systemId,
String baseSystemId, // +
String detectedEncoding)
throws XNIException;
For convenience, would it be useful to also pass the
expanded systemId as well?
[3] More Parser Interfaces
One of the problems I've run into (and I've mentioned
this before but I'll describe it again) is that while
we have a way to construct parser pipelines, we don't
have a way of actually initiating the pipeline in a
generic fashion.
In short, as Ted suggested, it would be cool if we
could define a pipeline dynamically. We can do most of
this today *except* for actually telling the scanner to
start scanning the input. Without this we can't swap
scanners arbitrarilly. And I want/need to be able to
do this! I don't want to have to rewrite an entire
parser configuration just to change from the fully
conformant scanner to a stripped-down "lite" scanner.
Which means that I need to define a new interface for
the document and DTD scanners. So here's a thought:
public interface XMLDocumentScanner {
public void startDocument(InputSource source)
throws IOException;
public boolean scanDocument(boolean complete)
throws XNIException, IOException;
}
public interface XMLDTDScanner {
public void startInternalSubset(InputSource source)
throws IOException;
public boolean scanInternalSubset(boolean complete,
boolean standalone,
boolean hasExternalDTD)
throws XNIException, IOException;
public void startExternalSubset(InputSource source)
throws IOException;
public boolean scanExternalSubset(boolean complete)
throws XNIException, IOException;
} // interface XMLDTDScanner
Right now the reference implementation of the scanners
depends on having an XMLEntityManager to handle the
entities and accessing an entity scanner capable of
tokenizing the lowest level input. So there is no
need to pass the input source to the scanners because
they get them from the entity manager. Of course,
making this kind of change impacts the scanners
directly. And I still don't have my head around how
this changes things.
[4] Remove Dependence on SAX
I kept the most controversial 'til last so that I only
get feedback from the real hardcore contributors. Or
from people who have nothing better to do than to read
really long posts on the mailing list... :)
Seriously, a point was raised at the Xerces2 Workshop: why
*do* we use the SAX stuff but only where appropriate? Why
not either extend SAX or just remove all dependence on SAX
and make a completely standalone set of interfaces?
Extending SAX raises a lot of problems that I won't go
into here but let's suffice it to say that it's not the
best option.
Since the Workshop I've been starting to agree with the
argument and want to remove dependence on all other APIs
from XNI. Therefore, I would suggest that we remove all
use of SAX throughout XNI. That means that we would
invent our own entity resolver, input source, etc. We
can make them look an awful lot like SAX so that it
bridges the learning gap between the two, though.
Diverging from SAX also lets us fix the problems that
SAX has. For example, there was a recent suggestion on
the xml-dev mailing list about extending SAX in the
future so that the entity resolver is passed the base
URI as well to allow the resolver to do more. I'm all
for this parameter. And I'm sure that there are more
instances like this.
So here's a proposal (in an abbreviated form):
public class XMLInputSource {
protected String fPublicId;
protected String fSystemId;
protected String fBaseSystemId; // +
protected String fExpandedSystemId; // +
protected String fEncoding;
protected InputStream fByteStream;
protected Reader fCharStream;
} // class XMLInputSource
public class XNIParseException extends XNIException {
protected XMLLocator fLocation;
}
public interface XMLLocator {
public String getPublicId();
public String getSystemId();
public String getBaseSystemId(); // +
public String getExpandedSystemId(); // +
public int getLineNumber();
public int getColumnNumber();
} // interface XMLLocator
public interface XMLErrorHandler {
public void warning(XNIParseException ex) throws XNIException;
public void error(XNIParseException ex) throws XNIException;
public void fatalError(XNIParseException ex) throws XNIException;
} // interface XMLErrorHandler
public interface XMLEntityResolver {
public XMLInputSource resolveEntity(String publicId,
String systemId,
String baseSystemId) // +
throws XNIException, IOException;
}
Am I missing anything?
[*] Start the Discussion!
Here's where you add your 2 cents (or yen, etc). I'll keep
this topic open throughout this week and then, barring any
problems, I'll start enacting the changes next week.
--
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
Re: [Xerces2] Design Decisions (LONG)
Posted by Ted Leung <tw...@sauria.com>.
----- Original Message -----
From: "Andy Clark" <an...@apache.org>
To: <xe...@xml.apache.org>
Sent: Wednesday, July 04, 2001 8:23 PM
Subject: Re: [Xerces2] Design Decisions (LONG)
> Elena Litani wrote:
> > Hmmm.. We do plan to implement DOM L3 specs and although we did not
> > discuss implementing Abstract Schema [AS] module (that allows editing
> > and querying grammars), the APIs are there. Do we want to provide
> > another way to access grammar??
>
> Are you confident that the DOM L3 ASLS is able to adequately
> model a grammar? I'm not. I'm sure it's sufficient (for some
> definition of "sufficient") for DTDs and XML Schema grammars
> but I'm not convinced it will be able to model other types
> of schema grammar languages.
>
> > I am not sure how DTDContentModelHandler is useful for editor writers.
>
> It's not supposed to be. And creating one that is useful
> causes the exponential interface explosion that we've seen
> from my various proposals. I'm not against providing some-
> thing useful for editor writers but that is not the primary
> purpose of the interface nor should it be.
>
> > In the world of XML Schemas, you better also provide support for editing
> > XML Schemas as well as DTDs, and DTDContentModelHandler provides way to
> > little information..
>
> That's why "DTD" is in the name of interface: because it's
> for DTDs, *not* XML Schemas.
>
> > My point is, I believe if we ever want to provide in Xerces APIs for
> > editing/querying AS (DTD, XML Schemas, other grammars), we better do it
> > by implementing standard DOM APIs.
>
> We "could" do it that way. Whether we "better" do it that
> way is open to debate.
It doesn't follow that because DOM (or SAX) have a particular API for
something that
we have to implement these API's directly in the parser. As soon as we get
into
editing grammars, then we go back to the problem of how they are represented
inside
the parser. That representation has to serve two purposes if we start to
talk about editing:
1) provide a high performance way to validate a document against a grammar
2) provide a rich enough representation that can be presented to an editor
and be pushed
back into the validator internals.
I think that these are probably 2 different representations.
> > > [2] Pass Base URI to startEntity Callback
> > > [...]
> >
> > Can baseSystemId be null?
>
> Yes, that would signify that there is no known base system
> identifier. However, I'm still trying to think of a situation
> where the systemId is *relative* but no base systemId is
> provided. Can anybody think of a use case?
>
> The point of passing this information is so that we don't
> munge data. The systemId parameter would be the exact
> identifier text that was specified in the declaration.
> In this way, the callee has access to all of the
> information. Without it we have two options: pass in only
> the systemId or pass in the expanded systemId. In the
> first case the callee doesn't have enough information to
> do something meaningful and in the second case the callee
> is not actually seeing what was defined in the decl.
>
> Yes, that information would be passed via the DTD handler
> (add that to my list of things that need to pass the base
> systemId) but then you're creating a dependency that you
> need to use both interfaces and keep state. The parser's
> already keeping the state, why not pass it along if we
> have already done the work, IMHO.
>
> > > [4] Remove Dependence on SAX
> >
> > If we are removing dependence on SAX, should we consider using DOM L3
> > APIs for error handling, entity resolver, input source?
>
> You're proposing that we remove one dependency to add
> another similar dependency. I'm trying to remove the
> dependency altogether, not just switch it to one that
> looks "better", even if that were the case.
>
> > Andy, you've mentioned that SAX raises a lot of problems, could you
> > expand on that? ..I am not sure why do we need to define again the same
> > interfaces that exist in both DOM and SAX??
>
> SAX and DOM are lossy. We're trying to avoid loss of
> document information by passing as much as possible
> (within reason). The SAX approach is better suited to
> building a parser because DOM cannot be used once the
> document size increases beyond size N, where N is
> some arbitrary large number. But even SAX can't be
> used directly because 1) it loses needed information
> in its handler interfaces; 2) the pipeline it creates
> is read-only (e.g. Attributes); etc.
>
> My proposal actually is more radical than what it
> first appears. I'm also suggesting that we take this
> opportunity to break backwards compatibility in order
> to do the right thing. Take, for example, parsing: the
> base XML parser class relies on SAX for setting
> features/properties, entity resolution, error handling,
> and parsing. Why would a DOM parser need such a
> dependency? No real reason.
>
> So what is the "right" thing? Depends on who you
> ask. If you ask the SAX people, they might say that you
> should use the parser factory helper classes to create
> the parser and then using the parser and handler
> interfaces defined. The DOM people might say that the
> right way is through the load/save component of DOM L3.
> Or they both might say using JAXP to create the parser
> and parsing documents. In none of these cases would I
> consider instantiating the parser class directly "the
> right thing to do".
>
> By defining our own fully-independent, internal API we
> remove all dependencies (because SAX and DOM are not the
> *only* way to output the document data from parsing an
> XML document) and improve the ability to layer parser
> components and configurations without carrying along
> unneeded dependencies. People using the SAX parser
> would do things the "SAX way"; people using the DOM
> parser would do things the "DOM way"; and none of them
> would have to do some things one way and do other
> things other ways just because we have built in a
> cross-dependency.
>
> Only people going *beyond* what is capable with the
> "standard" interfaces and taking advantage of the
> native APIs would ever know that there is a set of
> interfaces that look awfully similar to ones already
> present in SAX and DOM. Once the wrapper is built on
> top of the XNI stuff to expose it in the SAX way or
> the DOM way, people won't even know it's there.
>
> Can you tell I'm starting to feel pretty strongly about
> this point? ;)
>
> --
> 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] Design Decisions (LONG)
Posted by Andy Clark <an...@apache.org>.
Elena Litani wrote:
> Hmmm.. We do plan to implement DOM L3 specs and although we did not
> discuss implementing Abstract Schema [AS] module (that allows editing
> and querying grammars), the APIs are there. Do we want to provide
> another way to access grammar??
Are you confident that the DOM L3 ASLS is able to adequately
model a grammar? I'm not. I'm sure it's sufficient (for some
definition of "sufficient") for DTDs and XML Schema grammars
but I'm not convinced it will be able to model other types
of schema grammar languages.
> I am not sure how DTDContentModelHandler is useful for editor writers.
It's not supposed to be. And creating one that is useful
causes the exponential interface explosion that we've seen
from my various proposals. I'm not against providing some-
thing useful for editor writers but that is not the primary
purpose of the interface nor should it be.
> In the world of XML Schemas, you better also provide support for editing
> XML Schemas as well as DTDs, and DTDContentModelHandler provides way to
> little information..
That's why "DTD" is in the name of interface: because it's
for DTDs, *not* XML Schemas.
> My point is, I believe if we ever want to provide in Xerces APIs for
> editing/querying AS (DTD, XML Schemas, other grammars), we better do it
> by implementing standard DOM APIs.
We "could" do it that way. Whether we "better" do it that
way is open to debate.
> > [2] Pass Base URI to startEntity Callback
> > [...]
>
> Can baseSystemId be null?
Yes, that would signify that there is no known base system
identifier. However, I'm still trying to think of a situation
where the systemId is *relative* but no base systemId is
provided. Can anybody think of a use case?
The point of passing this information is so that we don't
munge data. The systemId parameter would be the exact
identifier text that was specified in the declaration.
In this way, the callee has access to all of the
information. Without it we have two options: pass in only
the systemId or pass in the expanded systemId. In the
first case the callee doesn't have enough information to
do something meaningful and in the second case the callee
is not actually seeing what was defined in the decl.
Yes, that information would be passed via the DTD handler
(add that to my list of things that need to pass the base
systemId) but then you're creating a dependency that you
need to use both interfaces and keep state. The parser's
already keeping the state, why not pass it along if we
have already done the work, IMHO.
> > [4] Remove Dependence on SAX
>
> If we are removing dependence on SAX, should we consider using DOM L3
> APIs for error handling, entity resolver, input source?
You're proposing that we remove one dependency to add
another similar dependency. I'm trying to remove the
dependency altogether, not just switch it to one that
looks "better", even if that were the case.
> Andy, you've mentioned that SAX raises a lot of problems, could you
> expand on that? ..I am not sure why do we need to define again the same
> interfaces that exist in both DOM and SAX??
SAX and DOM are lossy. We're trying to avoid loss of
document information by passing as much as possible
(within reason). The SAX approach is better suited to
building a parser because DOM cannot be used once the
document size increases beyond size N, where N is
some arbitrary large number. But even SAX can't be
used directly because 1) it loses needed information
in its handler interfaces; 2) the pipeline it creates
is read-only (e.g. Attributes); etc.
My proposal actually is more radical than what it
first appears. I'm also suggesting that we take this
opportunity to break backwards compatibility in order
to do the right thing. Take, for example, parsing: the
base XML parser class relies on SAX for setting
features/properties, entity resolution, error handling,
and parsing. Why would a DOM parser need such a
dependency? No real reason.
So what is the "right" thing? Depends on who you
ask. If you ask the SAX people, they might say that you
should use the parser factory helper classes to create
the parser and then using the parser and handler
interfaces defined. The DOM people might say that the
right way is through the load/save component of DOM L3.
Or they both might say using JAXP to create the parser
and parsing documents. In none of these cases would I
consider instantiating the parser class directly "the
right thing to do".
By defining our own fully-independent, internal API we
remove all dependencies (because SAX and DOM are not the
*only* way to output the document data from parsing an
XML document) and improve the ability to layer parser
components and configurations without carrying along
unneeded dependencies. People using the SAX parser
would do things the "SAX way"; people using the DOM
parser would do things the "DOM way"; and none of them
would have to do some things one way and do other
things other ways just because we have built in a
cross-dependency.
Only people going *beyond* what is capable with the
"standard" interfaces and taking advantage of the
native APIs would ever know that there is a set of
interfaces that look awfully similar to ones already
present in SAX and DOM. Once the wrapper is built on
top of the XNI stuff to expose it in the SAX way or
the DOM way, people won't even know it's there.
Can you tell I'm starting to feel pretty strongly about
this point? ;)
--
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
Re: [Xerces2] Design Decisions (LONG)
Posted by Elena Litani <el...@ca.ibm.com>.
Andy Clark wrote:
> [1] DTD Handler Interfaces
> I'm now leaning towards Glenn's earlier suggestion that we
> can provide DTD information needed to DTD editor writers
> (arguably a very small percentage of the parser user base)
> via the SAX xml-string property. I'm not suggesting that
> we *will* implement this before rolling out Xerces2, merely
> that we *can* support communicating more information in
> the future through this (or a similar) mechanism.
Hmmm.. We do plan to implement DOM L3 specs and although we did not
discuss implementing Abstract Schema [AS] module (that allows editing
and querying grammars), the APIs are there. Do we want to provide
another way to access grammar??
I am not sure how DTDContentModelHandler is useful for editor writers.
In the world of XML Schemas, you better also provide support for editing
XML Schemas as well as DTDs, and DTDContentModelHandler provides way to
little information..
My point is, I believe if we ever want to provide in Xerces APIs for
editing/querying AS (DTD, XML Schemas, other grammars), we better do it
by implementing standard DOM APIs.
> [2] Pass Base URI to startEntity Callback
>
> In the continuing effort to pass as much information via
> XNI as possible, I would suggest passing the base systemId
> when calling the startEntity method in all of the handlers
> that define this method.
> public void startEntity(String name,
> String publicId, String systemId,
> String baseSystemId, // +
> String detectedEncoding)
> throws XNIException;
Can baseSystemId be null?
> [4] Remove Dependence on SAX
If we are removing dependence on SAX, should we consider using DOM L3
APIs for error handling, entity resolver, input source?
Andy, you've mentioned that SAX raises a lot of problems, could you
expand on that? ..I am not sure why do we need to define again the same
interfaces that exist in both DOM and SAX??
Thx,
Elena
---------------------------------------------------------------------
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] Design Decisions (LONG)
Posted by Andy Clark <an...@apache.org>.
Andy Clark wrote:
> [2] Pass Base URI to startEntity Callback
Done.
Also fixed a long standing bug in the Xerces-J codebase that
prevented entities from being declared relative to relative
entities. Now Xerces2 can handle it.
--
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
Re: [Xerces2] Design Decisions (LONG)
Posted by Andy Clark <an...@apache.org>.
Andy Clark wrote:
> > [1] DTD Handler Interfaces
>
> Okay, basically nobody disagreed with this so I'm going to
> implement the changes to the interface and implementation.
Done.
--
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
Re: [Xerces2] Design Decisions (LONG)
Posted by Andy Clark <an...@apache.org>.
Andy Clark wrote:
> [1] DTD Handler Interfaces
Okay, basically nobody disagreed with this so I'm going to
implement the changes to the interface and implementation.
--
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
Re: [Xerces2] Design Decisions (LONG)
Posted by Andy Clark <an...@apache.org>.
Ted Leung wrote:
> -0 I still think that editor writing is out of the scope of
> the parser, but I may be the only one who thinks this.
The content model callbacks are not for editor writers, per
se, but rather to make it easier for the DTD validator to
construct the appropriate content models. Requiring everyone
to re-parse content models when all that work had to be done
in the scanner to assure well-formedness seems like a waste.
Which is why we put the XMLDTDContentModelHandler in there
in the first place.
The changes I proposed were to make things balance better.
Also, the "startContentModel(short type)" method caused
some implementation irritation that would be alleviated by
the interface changes.
> > For convenience, would it be useful to also pass the
> > expanded systemId as well
>
> We should only pass the expanded systemId if there's no way to construct
> it from the rest of the data -- which there is in this case.
Seems fine to me since it *can* be re-constructed from the
systemId and baseSystemId. Would be nice to have a utility
class to do this (or a static method on the URI class).
> Can we break this out as a separate discussion. I'd really like to
> see this work, and I think I have some time to put towards making
> this work.
Sure, I'll do just that. And I'll post the interfaces I
have already made up but haven't checked in.
--
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
Re: [Xerces2] Design Decisions (LONG)
Posted by Ted Leung <tw...@sauria.com>.
----- Original Message -----
From: "Andy Clark" <an...@apache.org>
To: <xe...@xml.apache.org>
Sent: Monday, July 02, 2001 11:42 PM
Subject: [Xerces2] Design Decisions (LONG)
> This list is eerily quiet these days in regards to Xerces2
> design and development. Hmmm... Well, I'm going to raise a
> few more design points and then make some unilateral
> decisions unless there's some discussion or objections.
>
> [1] DTD Handler Interfaces
>
> We've had some discussion but no resolution on what is to
> become of the XMLDTDHandler and XMLDTDContentModelHandler
> interfaces. Obviously the right balance of information and
> usefulness is beyond our reach.
>
> I'm now leaning towards Glenn's earlier suggestion that we
> can provide DTD information needed to DTD editor writers
> (arguably a very small percentage of the parser user base)
> via the SAX xml-string property. I'm not suggesting that
> we *will* implement this before rolling out Xerces2, merely
> that we *can* support communicating more information in
> the future through this (or a similar) mechanism.
>
> I'm still torn between 1 and 2 interfaces so I'm gonna
> stay with 2 separate interfaces. However, I would make
> the following changes to the XMLDTDContentModelHandler
> interface, in an attempt to provide a better callback
> interleaving with start/endEntity.
>
> public interface XMLDTDContentModelHandler {
>
> public static final short OCCURS_ZERO_OR_MORE = 0;
> public static final short OCCURS_ZERO_OR_ONE = 1;
> public static final short OCCURS_ONE_OR_MORE = 2;
>
> public static final short SEPARATOR_CHOICE = 3;
> public static final short SEPARATOR_SEQUENCE = 4;
>
> public void startContentModel(String elementName) // *
> throws XNIException;
>
> public void any() throws XNIException; // +
> public void empty() throws XNIException; // +
>
> public void startGroup() throws XNIException; // rename
> public void pcdata() throws XNIException; // +
> public void element(String name) throws XNIException; // rename
> public void occurs(short occurs) throws XNIException; // rename
> public void separator(short separator) throws XNIException; //
> rename
> public void endGroup() throws XNIException; // rename
>
> public void endContentModel() throws XNIException;
>
> } // interface XMLDTDContentModelHandler
-0 I still think that editor writing is out of the scope of the parser, but
I
may be the only one who thinks this.
> [2] Pass Base URI to startEntity Callback
>
> In the continuing effort to pass as much information via
> XNI as possible, I would suggest passing the base systemId
> when calling the startEntity method in all of the handlers
> that define this method.
>
> Therefore, the method would have the following prototype:
>
> public void startEntity(String name,
> String publicId, String systemId,
> String baseSystemId, // +
> String detectedEncoding)
> throws XNIException;
>
> For convenience, would it be useful to also pass the
> expanded systemId as well
We should only pass the expanded systemId if there's no way to construct
it from the rest of the data -- which there is in this case.
> [3] More Parser Interfaces
>
> One of the problems I've run into (and I've mentioned
> this before but I'll describe it again) is that while
> we have a way to construct parser pipelines, we don't
> have a way of actually initiating the pipeline in a
> generic fashion.
>
> In short, as Ted suggested, it would be cool if we
> could define a pipeline dynamically. We can do most of
> this today *except* for actually telling the scanner to
> start scanning the input. Without this we can't swap
> scanners arbitrarilly. And I want/need to be able to
> do this! I don't want to have to rewrite an entire
> parser configuration just to change from the fully
> conformant scanner to a stripped-down "lite" scanner.
>
> Which means that I need to define a new interface for
> the document and DTD scanners. So here's a thought:
>
> public interface XMLDocumentScanner {
> public void startDocument(InputSource source)
> throws IOException;
> public boolean scanDocument(boolean complete)
> throws XNIException, IOException;
> }
>
> public interface XMLDTDScanner {
>
> public void startInternalSubset(InputSource source)
> throws IOException;
> public boolean scanInternalSubset(boolean complete,
> boolean standalone,
> boolean hasExternalDTD)
> throws XNIException, IOException;
>
> public void startExternalSubset(InputSource source)
> throws IOException;
> public boolean scanExternalSubset(boolean complete)
> throws XNIException, IOException;
>
> } // interface XMLDTDScanner
>
> Right now the reference implementation of the scanners
> depends on having an XMLEntityManager to handle the
> entities and accessing an entity scanner capable of
> tokenizing the lowest level input. So there is no
> need to pass the input source to the scanners because
> they get them from the entity manager. Of course,
> making this kind of change impacts the scanners
> directly. And I still don't have my head around how
> this changes things.
Can we break this out as a separate discussion. I'd really like to
see this work, and I think I have some time to put towards making
this work.
> [4] Remove Dependence on SAX
>
> I kept the most controversial 'til last so that I only
> get feedback from the real hardcore contributors. Or
> from people who have nothing better to do than to read
> really long posts on the mailing list... :)
>
> Seriously, a point was raised at the Xerces2 Workshop: why
> *do* we use the SAX stuff but only where appropriate? Why
> not either extend SAX or just remove all dependence on SAX
> and make a completely standalone set of interfaces?
> Extending SAX raises a lot of problems that I won't go
> into here but let's suffice it to say that it's not the
> best option.
>
> Since the Workshop I've been starting to agree with the
> argument and want to remove dependence on all other APIs
> from XNI. Therefore, I would suggest that we remove all
> use of SAX throughout XNI. That means that we would
> invent our own entity resolver, input source, etc. We
> can make them look an awful lot like SAX so that it
> bridges the learning gap between the two, though.
>
> Diverging from SAX also lets us fix the problems that
> SAX has. For example, there was a recent suggestion on
> the xml-dev mailing list about extending SAX in the
> future so that the entity resolver is passed the base
> URI as well to allow the resolver to do more. I'm all
> for this parameter. And I'm sure that there are more
> instances like this.
>
> So here's a proposal (in an abbreviated form):
>
> public class XMLInputSource {
>
> protected String fPublicId;
> protected String fSystemId;
> protected String fBaseSystemId; // +
> protected String fExpandedSystemId; // +
>
> protected String fEncoding;
>
> protected InputStream fByteStream;
> protected Reader fCharStream;
>
> } // class XMLInputSource
>
> public class XNIParseException extends XNIException {
> protected XMLLocator fLocation;
> }
>
> public interface XMLLocator {
>
> public String getPublicId();
> public String getSystemId();
> public String getBaseSystemId(); // +
> public String getExpandedSystemId(); // +
>
> public int getLineNumber();
> public int getColumnNumber();
>
> } // interface XMLLocator
>
> public interface XMLErrorHandler {
>
> public void warning(XNIParseException ex) throws XNIException;
> public void error(XNIParseException ex) throws XNIException;
> public void fatalError(XNIParseException ex) throws XNIException;
>
> } // interface XMLErrorHandler
>
> public interface XMLEntityResolver {
> public XMLInputSource resolveEntity(String publicId,
> String systemId,
> String baseSystemId) // +
> throws XNIException, IOException;
> }
>
> Am I missing anything?
+0. Cleanliness on this is okay with me.
> [*] Start the Discussion!
>
> Here's where you add your 2 cents (or yen, etc). I'll keep
> this topic open throughout this week and then, barring any
> problems, I'll start enacting the changes next week.
>
> --
> 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