Well, part of my point was that, AFAICT, your approach doesn't serve the use-cases I envisage and did development for. It seems to me that a good basic XML parser would be a prerequisite to supporting the use-case you describe, and the Haskell type-conversion could be layered on top. As I understand it, that's how HaXML is constructed. As for the <textarea/> case you raise, this could be an area where HTML and XML give rise to differing requirements. Personally, I'd prefer an *XML* parser to stick to XML specifications. #g -- S. Alexander Jacobson wrote:
Again, my point is that it depends on the use cases we want to target.
My bias is that we should be targetting conversion between XML and application specific Haskell data types. Speculatively, I imagine a tool that generates Haskell datatypes and a parser from a RelaxNG specification and another that generates a RelaxNG spec from a haskell datatype. But that is just my hope. My immediate need is probably to adapt HWSProxyGen or HAifa to talk SOAP to paypal's api.
Other people may have other needs.
-Alex-
______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
On Tue, 30 May 2006, Udo Stenzel wrote:
S. Alexander Jacobson wrote:
The problem with the infoset is that <textarea></textarea> and <textarea/> mean different things for some web browsers.
So do <textarea/> and <textarea />. What's the point of pointing out that some browsers are broken? (Actually most are somehow broken when it comes to application/xml, but who's counting?)
Udo. -- "There are three ways to make money. You can inherit it. You can marry it. You can steal it." -- conventional wisdom in Italy
-- Graham Klyne For email: http://www.ninebynine.org/#Contact