xml in fptools?
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.
> 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?)
>> "There are three ways to make money. You can inherit it. You can marry
>> it. You can steal it."
>> -- conventional wisdom in Italy
More information about the Libraries