I have uploaded a patch[1] to remove the TSaxInputSource, it is redundant with TXmlInputSource from XmlReader unit.

I believe the TSAXXMLReader.Parse method have almost the same functionality of xmltextreader.TXMLTextReader.

I would like to know if and how it can be modified. The base class, TSaxReader, needs much more changing and could affect users of the class.

Thank you,

Daniel

[1] http://bugs.freepascal.org/view.php?id=25854

It can be changed. What else do you want to know ?

Michael.

12.03.2014 1:32, Daniel Gaspary пишет:

I had an idea of replacing SAX with proxy to TXMLTextReader once I've written the latter, but it appears that SAX is just beyond redemption. One case is that it reports attribute names in LocalName property instead of QualifiedName, which means that any code using SAX reads them from wrong place and *will* break if SAX is made compliant.

OTOH, if we go for breaking user's code, then it is much better to drop SAX altogether and switch over to TXMLTextReader.

From these points of view the best way is probably to document TXMLTextReader, deprecate SAX and leave it alone.

All above is about sax-xml; sax-html, unfortunately, does not have a better alternative in FPC packages.

Regards,
Sergei

Sergei Gorelkin wrote

OTOH, if we go for breaking user's code, then it is much better to drop SAX altogether and switch over to TXMLTextReader. From these points of view the best way is probably to document TXMLTextReader, deprecate SAX and leave it alone.

Seems to be the best alternative.

On other topic, a new StaX[1] class, using TXMLTextReader, seems need not too many work to accomplish. Am I sub estimating It ?

Daniel

[1] http://www.vogella.com/tutorials/JavaXML/article.html#javastax

Daniel Gaspary wrote

On other topic, a new StaX[1] class, using TXMLTextReader,

I mean, *classes*.

Creating the writer part too.

12.03.2014 18:10, Daniel Gaspary пишет:

Why would you want to use S[t]AX approach in the first place? The interface of .net-based XML[Text]Reader and XMLWriter is IMHO much more straightforward and easy to use.

Regards,
Sergei

Sergei Gorelkin wrote

Why would you want to use S[t]AX approach in the first place?

No special reason at the moment. I didn't examine TXmlTextReader so much yet.

The interface of .net-based XML[Text]Reader and XMLWriter is IMHO much more straightforward and easy to use.

A xmlwriter unit, equivalent to xmlreader, would be interesting.To have a XML writer independent of DOM.

12.03.2014 18:58, Daniel Gaspary пишет:

Here I fully agree, and in the meantime I've already committed some initial changes to TXMLWriter to make it function like .net XMLTextWriter.

Regards,
Sergei

Sergei Gorelkin wrote

Here I fully agree, and in the meantime I've already committed some initial changes to TXMLWriter to make it function like .net XMLTextWriter.

Are these changes at trunk? Fcl or LazUtils?

About DOM independence... something against XPath Scanner (at least) becoming a dom independent unit?

Curious: How can XPath become dom independent ?
I thought the result of XPath was a series of DOM nodes ?

Michael.

Michael Van Canneyt wrote

Curious: How can XPath become dom independent ? I thought the result of XPath was a series of DOM nodes ?

Yes, it is. But I'm thinking about using the XPath expressions in other classes.

Maybe a TXmlTextReader descendent with support to some kind of "realtime XPath Filter"

Like executing an Event Procedure every time a specific XPath Expression is matched.

I seriously doubt this is doable, since XPath works directly on the DOM tree ?

What can be achieved at the most seems to be the parsing of the expression and the resulting parse tree. Which, I agree, would be useful to have available as a separate set of classes.

Michael.

Michael Van Canneyt wrote

What can be achieved at the most seems to be the parsing of the expression and the resulting parse tree.

Is exactly what I'm trying to say(my lack of English grammar skills doesn't help). :)

I seriously doubt this is doable, since XPath works directly on the DOM tree ?

Is possible if TXmlReader keeps track of the it's current path. Let's say:

TMyXmlReader = class(TXmlTextReader)
private
         FPath: TStrings; //or another dedicated new CLass to keep a
list of nodes.
public
        Register(XPathExpression: string; MethodToCall);
end;

At each step of processing, FPath is updated and is compared to XPathExpression.

12.03.2014 21:46, Daniel Gaspary пишет:

A certain subset of expressions (forward iteration only) can be handled that way, yes. But in general, XPath requires a source with non-sequential access.

Regards,
Sergei

Sergei Gorelkin wrote

A certain subset of expressions (forward iteration only) can be handled that way, yes. But in general, XPath requires a source with non-sequential access.

Beyond this use case, could be useful to other implementations of XML, tree based ones.