saxdotnet-devel

[Saxdotnet-devel] Merging the IXmlReaderControl with IXmlReader

[Jeff R. <je...@je...>]

Karl has proposed merging the IXmlReaderControl functionality into the 
IXmlReader. This would add a "Suspend" and "Resume" function to the core 
XmlReader. For implementations that do not support this behavior 
(AElfred) calling these methods would generate a NotSupportedException.

Additionally, a Status interface level property would be added to 
indicate the current read status. Although taken from the 
IXmlReaderControl interface, it is not optional, since it is easy to 
implement for any IXmlReader - it will just never return a value of 
XmlReaderStatus.Suspended for some IXmlReaders.

As the implementer of AElfred I see no problem with this...

Jeff Rafter

Re: [Saxdotnet-devel] Merging the IXmlReaderControl with IXmlReader

[Elliotte H. <el...@me...>]

Jeff Rafter wrote:

> Karl has proposed merging the IXmlReaderControl functionality into the 
> IXmlReader. This would add a "Suspend" and "Resume" function to the core 
> XmlReader. For implementations that do not support this behavior 
> (AElfred) calling these methods would generate a NotSupportedException.
> 

Is it possible these could be no-ops instead of throwing exceptions? I 
find all this talk of methods that sometimes work and sometimes don't to 
be very confusing.

For a class like XmlReader that is accessed directly by the programmer, 
rather than being passed in as an argument or used through a callback, 
wouldn't it be preferable to have subclasses with extra functionality? 
Why do we need to stuff every method into one interface?

-- 
Elliotte Rusty Harold  el...@me...
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim

Re: [Saxdotnet-devel] Merging the IXmlReaderControl with IXmlReader

[Karl W. <ka...@wa...>]

> Is it possible these could be no-ops instead of throwing exceptions? I 
> find all this talk of methods that sometimes work and sometimes don't to 
> be very confusing.
> 
> For a class like XmlReader that is accessed directly by the programmer, 
> rather than being passed in as an argument or used through a callback, 
> wouldn't it be preferable to have subclasses with extra functionality? 
> Why do we need to stuff every method into one interface?

Mostly for simplicity of coding.
Let's say your factory returns an IXmlReader.
Then you just check the reader-control feature
(I think we haven't metioned that yet)
and go on coding with Resume() and Suspend().

Otherwise you have to perform a type cast, and you
have to use a second variable of type IXmlReaderSubclass
as initally all you got is an IXmlReader.

Or, as it was with the old and separate IXmlReaderControl
interface, you have to keep two references to the parser,
one for the standard IXmlReader functionality, and one for
using the suspend/resume feature.

Karl 

Re: [Saxdotnet-devel] Merging the IXmlReaderControl with IXmlReader

[Elliotte H. <el...@me...>]

Karl Waclawek wrote:


> Mostly for simplicity of coding.
> Let's say your factory returns an IXmlReader.
> Then you just check the reader-control feature
> (I think we haven't metioned that yet)
> and go on coding with Resume() and Suspend().

I don't find this simpler at all. The simple, obvious solution is to 
either have a separate factory that creates suspendable parsers or have 
a separate getSuspendableReader method. If the client knows they want a 
suspendable parser, then let them ask the factory for one instead of 
asking for some parser and getting back Lord knows what.

It might be worth looking at how JAXP's SAXParserFactory class works and 
consider using something along those lines that allows you to set 
features and properties on the factory rather than on each individual 
XmlReader.

-- 
Elliotte Rusty Harold  el...@me...
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim

Re: [Saxdotnet-devel] Merging the IXmlReaderControl with IXmlReader

[Karl W. <ka...@wa...>]

> Karl Waclawek wrote:
> 
> 
> > Mostly for simplicity of coding.
> > Let's say your factory returns an IXmlReader.
> > Then you just check the reader-control feature
> > (I think we haven't metioned that yet)
> > and go on coding with Resume() and Suspend().
> 
> I don't find this simpler at all. The simple, obvious solution is to 
> either have a separate factory that creates suspendable parsers or have 
> a separate getSuspendableReader method. If the client knows they want a 
> suspendable parser, then let them ask the factory for one instead of 
> asking for some parser and getting back Lord knows what.

And what if the client doesn't know?
What if an application provides extra functionality depending
on whether the system configured parser supports it?

Even the demo application works like that.
 
> It might be worth looking at how JAXP's SAXParserFactory class works and 
> consider using something along those lines that allows you to set 
> features and properties on the factory rather than on each individual 
> XmlReader.

In general, adding such functionality to the factory might be useful,
regardless of the above. Do you have a link at hand?
If not, don't bother, I'll search Google.

Karl

Re: [Saxdotnet-devel] Merging the IXmlReaderControl with IXmlReader

[Elliotte H. <el...@me...>]

Karl Waclawek wrote:


> 
> In general, adding such functionality to the factory might be useful,
> regardless of the above. Do you have a link at hand?


http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/parsers/SAXParserFactory.html

Be careful. There's a lot of stuff in that class (like it's lack of 
namespace awareness by default) we don't want to imitate.

-- 
Elliotte Rusty Harold  el...@me...
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim