Graham Klyne wrote:

Which leads me to a question: starting from the haskell.org web page, I have identified three XML parsers in Haskell (HaXml, hXML, Haskell XML Toolbox), none of which seem to support XML namespaces and only one of which claims to be tested on both HUGS and GHC.

Can anyone offer any recommendations, or maybe pointers to other work?

What are you looking for in an XML toolkit? As far as HXML goes, I have a rough sketch of an implementation of XML namespace support, not yet finished or released. (This is a somewhat thorny problem; implementing XMLNS is not hard, but implementing it in a sane way requires some ingenuity.) --Joe English jenglish@flightlab.com

Graham Klyne had some questions about XML parsing in Haskell. Here is the current state of play with HaXml.

1. Works with HUGS and GHC (I'm currently developing with HUGS, but anticipate using GHC for "production" code).

HaXml certainly works with ghc (and ghci). It probably still works with Hugs too - the only current unresolved issue there is how to package it up nicely for Hugs (cpp #ifdefs, installation location, etc).

2. Namespaces, though I'm prepared to roll-my-own on top of an existing XML parser.

About a year and half ago, someone did some work on adding namespaces to HaXml, but it never got folded back into the main distribution. It may be possible to port that solution into the current tree (I can give you a contact email).

3. Well-formedness checking would be nice; i.e return a useful error indication if tags are mismatched, that sort of thing.

HaXml does well-formedness checking, although the quality of the error messages may not always be the best. (An ambiguous parse sometimes causes the error message to point to the wrong location.)

4. Validation is not required for my application.

HaXml also does validation, and the error messages here are actually very helpful.

I also thought briefly about adding namespace support, and contemplated replacing your type Name = String -- from memory, maybe not exactly right? with something like data Name = QName String String where the two strings would be namespace URI and local name respectively. I haven't yet figured what the cascading effects of such a change might be.

I imagine the same approach would would equally well in HaXml as in HXML.

BTW, do you have a test suite for your parser?

Not as such. However, the SMIL 2.0 and DocBook DTDs go through smoothly, and they are fairly large and complicated beasts. Regards, Malcolm

Graham Klyne wrote:

Joe English wrote:

...

What are you looking for in an XML toolkit?

Hi, thanks for responding. My desiderata:

1. Works with HUGS and GHC (I'm currently developing with HUGS, but anticipate using GHC for "production" code).

HXML works with Hugs, GHC, GHCI, and NHC, with the caveat that under Hugs it suffers from a space leak, which limits the size of documents that can be processed. I believe the other XML toolkits also work under all major Haskell implementations, or can be made to do so with a little effort.

2. Namespaces, though I'm prepared to roll-my-own on top of an existing XML parser.

See below for my thoughts on this...

3. Well-formedness checking would be nice; i.e return a useful error indication if tags are mismatched, that sort of thing.

OK; I'll add that to the TODO list for HXML. HaXml does some well-formedness checks (mismatched end-tags, doesn't look like it handles duplicate attribute values though.) The XML Toolbox does WF checking and validation.

4. Validation is not required for my application.

...

As far as HXML goes, I have a rough sketch of an implementation of XML namespace support, not yet finished or released. (This is a somewhat thorny problem; implementing XMLNS is not hard, but implementing it in a sane way requires some ingenuity.)

I was looking at HXML yesterday, and it has the great advantage that I feel I can understand it well enough to tinker. And the code looks clean to my Haskell-inexperienced eye. The main drawback is the lack of well-formedness checking, but think I could live with that, at least for prototyping purposes.

I think your presentation of an XML parse as a tree of XMLNodes closely matches what I want to do. Would it make sense to add a new node constructor indicating a syntax error?

That's a good idea. There's something similar in the [XMLEvent] representation (HXML's lazy functional equivalent of SAX). ErrorEvents presently turn into hard errors when the tree is built, but a separate XMLNode type for errors would allow these to be propagated into the Tree view without introducing unnecessary strictness.

I also thought briefly about adding namespace support, and contemplated replacing your

type Name = String -- from memory, maybe not exactly right?

with something like

data Name = QName String String

where the two strings would be namespace URI and local name respectively.

That's what most XML toolkits do (i.e., treat Names as URI + local-name pairs). I don't think this is the best way to do things though; this can lead to monstrosities like: case nodeName node of QName "http://www.w3.org/1999/xhtml" "p" -> ... QName "http://www.w3.org/1999/xhtml" "h1" -> ... QName "http://www.w3.org/1999/xhtml" "pre" -> ... This can be simplified, of course, but it's really much easier if you can treat names as atomic strings (just like in SGML and in pre-Namespaces XML): case nodeName node of "html:p" -> ... "html:h1" -> ... "html:pre" -> ... The approach I'm thinking of is to let the application programmer define an "internal" namespace environment, then rewrite element and attribute names in the parsed document to use the locally-defined prefixes.

I haven't yet figured what the cascading effects of such a change might be. Better, maybe, I define a new XMLnode type that uses QName instead of Name, and write a function to translate a (Tree XMLNode) to a (Tree XMLQNode)? That keeps things cleanly separated.

Another approach is to parameterize XMLNode on the type of names (XMLNode String vs. XMLNode QName). Or, you could store the namespace name and local name using James Clark's notation, "{http://www.w3.org/1999/xhtml}p"

BTW, do you have a test suite for your parser? (I've found the HUnit library to be very useful, and easily transferred my previous experience with JUnit.)

No, but I really should. Another one for the TODO list :-) --Joe English jenglish@flightlab.com

Shae Matijs Erisson wrote:

Do you have a version of HXML + (any) namespace support online or otherwise available for playing with? I'd like to try it.

Not yet, but stay tuned. --Joe English jenglish@flightlab.com

Haskell has nice syntactic support for unnamed product types (tuples). It is as though there were builtin several datatype definitions of the form: data (a,b) = (a,b) data (a,b,c) = (a,b,c) data (a,b,c,d) = (a,b,c,d) ... But for sum types, there is only one generic definition: data Either a b = Left a | Right b If needed, we could define our own versions for larger sum types. data Either3 a b c = Left3 a | Mid3 b | Right3 c data Either4 a b c d = Left4 a | LMid4 b | RMid4 c | Right4 d But the naming is already getting pretty ugly. Why the bias in syntactic support for products over sums? I propose syntactic support for unnamed sums. Here is one way to remedy the asymmetry. data (a|b) = [a|] | [|b] data (a|b|c) = [a||] | [|b|] | [||c] data (a|b|c|d) = [a|||] | [|b||] | [||c|] | [|||d] ... Here are some functions defined in this extended syntax for sums, along with their duals for products. {- the either function from the Prelude -} either :: (a -> c) -> (b -> c) -> (a|b) -> c either f g [a|] = f a either f g [|b] = g b both :: (a -> b) -> (a -> c) -> a -> (b,c) both f g a = (f a, g a) mapSum :: (a -> b) -> (c -> d) -> (a|b) -> (c|d) mapSum f g [a|] = [ f a |] mapSum f g [|b] = [| f a ] mapProd :: (a -> b) -> (c -> d) -> (a,b) -> (c,d) mapProd f g (a,b) = (f a, g b) distProd :: (a,(b|c)) -> ((a,b)|(a,c)) distProd (a,[b|]) = [(a,b)|] distProd (a,[|c]) = [|(a,c)] At this point, the parenthesis in the types are kind of bulky. It might be nicer to write products with * and sums with +. distProd :: a*(b+c) -> a*b + a*c What do people think about this? Has anyone else ever wished they had such support for unnamed sums? Does this syntax grate on people or does it look reasonable? Does anyone have thoughts on why Haskell is biased towards products? Nathan Linger Student at OGI www.cse.ogi.edu

Looks nice to me. For consistency, how about "(||c)" instead of "[||c]", of type (a|b|c). Also, I think you mean mapSum f g [|b] = [| g b ] - Conal -----Original Message----- From: haskell-admin@haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of Richard Nathan Linger Sent: Friday, February 21, 2003 4:28 PM To: Haskell Mailing List Subject: proposal for anonymous-sum syntax Haskell has nice syntactic support for unnamed product types (tuples). It is as though there were builtin several datatype definitions of the form: data (a,b) = (a,b) data (a,b,c) = (a,b,c) data (a,b,c,d) = (a,b,c,d) ... But for sum types, there is only one generic definition: data Either a b = Left a | Right b If needed, we could define our own versions for larger sum types. data Either3 a b c = Left3 a | Mid3 b | Right3 c data Either4 a b c d = Left4 a | LMid4 b | RMid4 c | Right4 d But the naming is already getting pretty ugly. Why the bias in syntactic support for products over sums? I propose syntactic support for unnamed sums. Here is one way to remedy the asymmetry. data (a|b) = [a|] | [|b] data (a|b|c) = [a||] | [|b|] | [||c] data (a|b|c|d) = [a|||] | [|b||] | [||c|] | [|||d] ... Here are some functions defined in this extended syntax for sums, along with their duals for products. {- the either function from the Prelude -} either :: (a -> c) -> (b -> c) -> (a|b) -> c either f g [a|] = f a either f g [|b] = g b both :: (a -> b) -> (a -> c) -> a -> (b,c) both f g a = (f a, g a) mapSum :: (a -> b) -> (c -> d) -> (a|b) -> (c|d) mapSum f g [a|] = [ f a |] mapSum f g [|b] = [| f a ] mapProd :: (a -> b) -> (c -> d) -> (a,b) -> (c,d) mapProd f g (a,b) = (f a, g b) distProd :: (a,(b|c)) -> ((a,b)|(a,c)) distProd (a,[b|]) = [(a,b)|] distProd (a,[|c]) = [|(a,c)] At this point, the parenthesis in the types are kind of bulky. It might be nicer to write products with * and sums with +. distProd :: a*(b+c) -> a*b + a*c What do people think about this? Has anyone else ever wished they had such support for unnamed sums? Does this syntax grate on people or does it look reasonable? Does anyone have thoughts on why Haskell is biased towards products? Nathan Linger Student at OGI www.cse.ogi.edu _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell