Restricted Types and Infinite Loops

[Simon David Foster]

On Fri, 2005-02-18 at 02:18 +0100, Ralf Laemmel wrote:

> Here I assume that you don't _really_ depend on ClassB to be a 
> superclass of ClassA. (Why would you?)

Ok, here's what the real class head is (or was before I butchered it to
make it work);

class (Data (DictXMLData h) a, XMLNamespace a) => XMLData h a where

We want to do this so that it is unnecessary to store XML Namespaces in
the XMLData instances (which is supposed to be for only encoding). There
are two reasons why this is necessary;

* 1 - We have another class XSDType a, which gives types an XSD Type.
This also depends on the types having a namespace. If we don't have this
class dependency, we end up with repeated data.
* 2 - In various contexts, you will require a different namespace for a
particular element, but the same encoder. For example, when creating a
SOAP Envelope, the "int" data-type could have the SOAP Encoding
namespace or it could have the XSD Namespace. Further it may not have a
namespace at all, in which case the default instance (XMLNamespace a)
will take over. By taking the dependency out you bind a particular
namespace to an encoder.

For now, the various encoders for XSD data-types are in the XSD Module,
this means that any user that wants to encode an int or string must
import the XSD module, since we can't centralise the encoder.

> This is a simpler recursion scheme in terrms of class/instance constraints.

Maybe, but sadly it doesn't achieve my goal. I could do Namespaces via a
hook, but that makes the construction and encoding of namespace tables
almost impossible.

Thanks,

-Si.

-- 
Simon David Foster <s.d.f at btinternet.com>