xml in fptools?

[Graham Klyne]

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