xml in fptools?

Graham Klyne GK at ninebynine.org
Wed May 31 05:44:55 EDT 2006

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.


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:

More information about the Libraries mailing list