Re: [gobo-eiffel-develop] XPointer (and xml:id)

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> I was about to reply to your previous message.

I still haven't seen it. There definitely appears to be a problem with
the mailing list at the moment.

    Eric> for this matter it is probably better to wait for Franck's
    Eric> approval than mine.

I think so too.

    Eric>  From what I understand though, having it in
    Eric> library/xml/xpath/xpointer shows the dependence between
    Eric> xpointer and xpath.

Actually, that's only an implementation dependence (although some
XPointer schemes (such as the unapproved xpointer() scheme, and
the gexslt:xpath() scheme which i devized) DO depend upon XPath, the
framework, and the current approved schemes (element() and xmlns())
don't depend upon XPath).

    Eric> I were to use the XML library and wanted to see if it
    Eric> supports XPointer without looking at the doc I would most
    Eric> likely try to see if there is a cluster
    Eric> library/xml/xpointer.

My point was, if we wanted to have an implementation for the tree
cluster (XM_NODE etc.), then it might be better to have an interface
directory (xml/xpointer) plus implementation directories
(xml/xpath/xpointer, xml/tree/xpointer).

And even if we cannot come up with a common interface (but I think
that might be possible, using generics), then the same cluster
structure might still be appropriate, with xml/xpointer just
containing a README.txt file, mentioning where the implementations
were).
But I don't know how feasible an implementation based upon xml/tree
will be, as i am not at all familiar with it.

Looking at my class XM_XPATH_XPOINTER (and if we decide to move the
cluster up a level, abandoning the idea of multiple implementations,
then I would rename this to XM_XPOINTER), I suspect that only two
generics (possibly a third, constrained, generic might be necessary)
would be necessary for a common interface.
-- 
Colin Paul Adams
Preston Lancashire