understanding HaXml and escaping

[Malcolm Wallace]

[moving discussion from Haskell list to libraries list]

"S. Alexander Jacobson" <alex at alexjacobson.com> writes:

> It would be helpful to have an example of
> using combinators to take a value of type e.g.
> 
>   import Network.URI
>   import System.Time
>   data Foo = Foo {uri::URI,
> 		  name::String,
> 		  stamp::ClockTime}
> 
> and produce e.g. a string such as
> 
>   <? xml version="1.0" ?>
>   <? xml-stylesheet type="text/xsl" href="myStyle.xsl"?>
>   <Foo xmlns:Foo="http://mynamespace"
>      uri="http://someURL" name="blah"
>      stamp="Mon, 11 Oct 2004 09:05:31 -0400"/>

Well, fundamentally, this kind of conversion is dependent not only
on the Haskell type defined by your application, but also the way you
want to represent it in XML.  There are lots of possible choices for
the latter.  The DRiFT implementation that derives the Haskell2Xml
class makes one choice for the type mapping, using nested elements -
you have made a rather different choice that uses attributes instead.
Neither is more "correct" - it is a stylistic judgement.

Although one could perhaps define some kind of meta-language for
describing various kinds of HaskellType -> XMLType translation,
with an automatic processor to derive a particular translation
for the type instances you want today, that is probably overkill.
Why not just write the specific mapping by hand in the first place
(as you have now done)?

> Note, I think I've figured out how to do this
> using raw types (after modifying to allow PIs in
> the prolog!), but I assume using the combinators
> is more correct.

No, the combinators are not "more correct".  They are just one
possible implementation choice, heavily biased towards XML -> XML
transformations.  If you are mainly generating documents rather than
transforming them, then the combinators might be unhelpful.  So just
use the raw XML element etc types instead.  At least you can re-use
the parser, validator, and pretty-printer.

> But I actually think the document function should
> *automatically* implement xmlEscape.  Otherwise,
> it is too easy for the user to produce incorrect
> documents notwithstanding what the library claims
> to promise!

Yes, good point.

> Will this work to insert a PI before the first
> element?

No, the CFilter combinators only manipulate the element content,
not the DTD or Prolog.  (Other XML toolboxes may have made different
choices here - I think Uwe Schmidt's HXT allows combinator-processing
of the DTD for instance.)

Regards,
    Malcolm