RE: XP Service URIs

Allowing optional expression of destination URI sounds like a good idea.

Does expression of the destination URI need to be in the base protocol or is
it sufficient if the base protocol has sufficient extensibility mechanisms
so that destination URI (and other routing information?) can be added?

I tend to think of this and similar questions as though we are asking of XML
whether the XML 1.0 specification needed to define a "person" element, a
"title" element, etc. or whether it is sufficient to do as XML 1.0 did and
provide only the extensibility mechanism.  XML 1.0 plus namespaces certainly
did define a few things, for example the "xmlns" attribute and namespace.
Is routing information more like "xmlns" or more like "title"? 

-----Original Message-----
From: Mark Nottingham [mailto:mnot@akamai.com]
Sent: Tuesday, November 21, 2000 2:45 PM
To: Frystyk
Cc: rden@loc.gov; XML Distributed Applications List
Subject: Re: XP Service URIs



Hmm. Perhaps then it should be a requirement for the protocol binding to
provide a way to determine the request-URI; if there isn't one inherent, it
must be transferred in the envelope. Modules which need greater confidence
in the URI should specify that it be transferred in the envelope in a
pre-arranged fashion (ideally, once for all modules, not once per module).


On Tue, Nov 21, 2000 at 02:33:56PM -0800, Henrik Frystyk Nielsen wrote:
> Ah, I see, you are talking about the request-URI so to speak - I thought
> you meant "service" as in "module".
> 
> It does make a lot of sense to have a header that knows about the XP (or
> SOAP) message path model and can indicate under what conditions to send
> the message to whom etc. However, I don't think it should be required as
> several protocol bindings (most of the *transfer* protocols like HTTP,
> SMTP etc.) have mechanisms for indicating where to send the message.
> 
> Henrik
> 
> > Confused - the service URI will most likely *not* be the XMLNS of the
> > message/modules...
> 

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

Received on Tuesday, 21 November 2000 18:03:25 UTC