At 17:45 13/05/04 +0100, MR K P SCHUPKE wrote:

Just sticking in my two pence worth...

I am not sure what application you intend this for, but I find most XML parsers completely useless. With my application programmers hat on, I do not want to validate against a DTD, I want to extract as much information as possible from bad XML... what I would like is a correcting parser - one which outputs XML in compliance, but will accept any old rubbish and make a best guess attempt to fix it up (based on a set of configurable heuristic rules)...

I would think this is a rather specialized requirement. I certainly don't want a "correcting" parser for my work. But I can see that some applications might...

Secondly I deal with very large documents, the tree form of which won't fit in memory, so I would see an XML parser doin the following...

parser :: String -> [XmlElements]

filter :: [XmlElements] -> [XmlElements]

reader :: [XmlElements] -> ... output data types ...

writer :: ... input data types ... -> [XmlElements]

render :: [XmlElements] -> String

In order to keep track of the tree structure the tree-depth of each element is encoded within the XmlElement type... thus allowing the data to be streamed through the filters/readers etc. This means the parser can output the first element as soon as it encounters the second element (lazy list == stream in Haskell) rather than having to wait until the last element as would happen with a DOM tree (it is a tree not a graph as XML elements can only contain sub-elements)...

This seems reasonable, and I'd expect a reasonable implementation (of a filter) to stream via lazy evaluation where that matches the final usage pattern. The outline I sketched (copied below) was intended to be built upon something like HaXML's filter idea, so that streaming processing would (in principle) be possible. My requirement is not to generate yet more XML, but to extract something quite different from the XML, so I think I'd be looking for something like your 'reader', which could be part of the lowest element in my diagram.

As I said the above is just my opinion, and as it happens I have written a parser that does the above... I guess that is why there are several parsers for XML available (different requirements) and there will probably be many more ...

I agree about the different requirements, but I think it would be good if this didn't mean different XML libraries; I'm fishing for an arrangement that allows the different requirements to be satisfied from common (or overlapping) components. I like your suggested parser/filter/reader/writer/render model, and I'll consider how that fits with the existing libraries (I really don't want to start from scratch here). I guess a 'parser' could be a special case of 'writer', and 'render' a special case of 'reader'. #g -- (Reprise of last part of my previous message...) What do I think an XML library for Haskell should look like? The component's I'd like to see would look something like this: XML parser :: String ---> (internal representation) | \ | -----> IO function to perform full validation | and external DTD handling [optional] v XML filter combinators --+--> entity substitution logic | +--> namespace handling | +--> XSLT processing [optional, for now **] v DOM-like read-only interface for access to data at level comparable to XML infoset (used to avoid dependency between applications that use infoset data and details of the internal representation used.) ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact