Re: Finalised Glossary Definitions

My .02 -

To me, the namespace is a natural way to do this; it identifies the
Module (current definition) whose functionality is desired, and
installed handlers on the node will identify which functionalities
they implement, by the same namespace. I don't think this is unduly
overloading it; it's being used as an identifier for the semantics of
the tags it describes.

Using a separate identifier doesn't really add anything, unless it's
felt that there is an additional, orthoganal way needed to describe
the desired handler. It bloats the message, and increases the amount
of administrative details associated with messages (a namespace URI
and a module-functionality URI).

Do we have any use cases (documented or not) where handlers (not
processors) need to be targetted in this manner?

Cheers,


On Tue, Mar 20, 2001 at 10:15:04AM +0100, Jean-Jacques Moreau wrote:
> Henrik Frystyk Nielsen wrote:
> 
> > [In SOAP]
> > Handlers as such do not have names as they are always associated with a
> > processor. However, modules have names which is the XML NS URI of that
> > module. How a processor finds a handler is an implementation choice but
> > it could for example be based on the XML NS URI of the module.
> >
> > When we look at the XML NS URIs and the actor URIs we in fact have two
> > names in a SOAP message:
> >
> >   * The actor URI identifies the "name" of the receiving SOAP processor
> >   * The XML NS URI identifies the "type" of the block.
> >
> > [...]
> 
> Henrik, I had always been thinking of namespaces as a way to avoid
> XML-tagname clashes, no more. You are suggesting that XMLP also uses
> namespaces to "name" ("type"?)  modules, which I would have done instead
> through an additional attribute. From your knowledge, it this particular use
> of namespaces suggested by the XML Namespace spec? is it common practice?
> 
> Jean-Jacques.
> 

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Tuesday, 20 March 2001 10:24:21 UTC