HaXml revisions (continued)

Graham Klyne gk at ninebynine.org
Thu Jun 17 13:48:32 EDT 2004


Further to my previous message [1], I've created a new snapshot [2] of my 
developments to the HaXml package.  Browseable source code is at [3].  It 
relies on a version of Network functions that are at [4].  The main feature 
of this release is the addition of a "filter" to perform general entity 
substitution in the parsed XML, and some fixes to the parameter entity 
substitution.

[1] http://www.haskell.org//pipermail/libraries/2004-June/002243.html
[2] http://www.ninebynine.org/Software/HaskellUtils/20040617-Haxml-1.12.zip
[3] http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/
[4] http://www.ninebynine.org/Software/HaskellUtils/20040609-Network.zip

The additions have necessitated some further reorganization of the handling 
of entity definitions, in order that some of the more subtle examples noted 
in the XML specification work as documented.

The code still needs some tidying up, but it works on all the test cases 
I've assembled to date.

Next steps are:
- create a test suite for XML validation, based on the W3C conformance test 
suite, and make sure the validation functions (still) work.
- tidy up the code, in particular with a view to pruning out deadwood.
- create a filter to perform namespace processing (that which got me 
started on all this in the first place).

...

There's one change I've made which I'm not entirely happy with:  in order 
to be able to collect diagnostic information from XML filter (CFilter) 
processing, I've added an option CErr to the XML content model.  A cleaner 
solution would, I think, be to extend the return type of a CFilter value, 
but this would be a significant change to the package interface in an area 
that I assume is particularly used by applications.

...

I've created separate code paths for internal (non-IO) and external (IO 
using) entity processing, but currently external entities are read using 
unsafePerformIO.  I've thought a little about trying to have the "external" 
interfaces return an IO value, and avoid using unsafePerformIO, but I can't 
currently see how to do that without sacrificing a very high degree of code 
sharing that is currently achieved.

As I write this, I think I've just realized how to do this.  If all the 
relevant shared code runs in some unspecified monad (i.e. is polymorphic in 
a monadic return type), then the non-IO code can use an identity monad and 
simply pick out the resulting value as a pure value, but code which depends 
on IO will be forced to return an IO value (or use unsafe...).  Does this 
sound plausible?

...

#g
--

[1] http://www.haskell.org//pipermail/libraries/2004-June/002243.html

[2] http://www.ninebynine.org/Software/HaskellUtils/20040617-Haxml-1.12.zip

[3] http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/

[4] http://www.ninebynine.org/Software/HaskellUtils/20040609-Network.zip



------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact



More information about the Libraries mailing list