OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [bt-spec] RE: Proposal to resolve URI issue


So, what are the cases when one wants to consider an identifier as an
address too?

-Identifier is not reachable (is not an address), is a URN
-Address is reachable (can be located), used for end-points, is a URL

Both identifier and address are URIs. One is locatable and the other is not.

Also, the same question that Peter asked.

>Is the determination that a particular URI in a payload-id is type A or
type
C (i.e. whether or not it can be used for addressing) on the basis of the
"application environment", or on the basis of some part of the URI itself ?

>Does "putting structure on the BTP URIs" mean defining one or several BTP
URI schemes ? [perhaps best clarified by example - what URI scheme(s) would
you expect for payload-id and "optional URIs for addressing" where the
binding was the soap-http-1 that we have in the spec, when used in the
"common", interoperable way? )

BTP URI schemes seems like a bad idea. We already have elements which define
the context in which these URIs are used. e.g. The value of element
<x-identifier> should not be used to locate x. The value of element
<y-address> should not be used to uniquely identify y.

Am I missing something here?

sanjay


-----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: Wednesday, January 30, 2002 7:06 AM
To: BT - spec
Subject: [bt-spec] RE: Proposal to resolve URI issue



> Can we consider this as an alternative proposal to the
> URI/identity/address
> issue?

ok, this seems good, as clear alternatives.

but there are still terminology problems, which mean we aren't understanding
each other's proposals.  (I'm accepting use of some terms for this
discussion that I don't want to see in the spec, by the way)

> We all seem to agree that we should use URIs across the board, i.e., at
> addressing and identification level (which I'll refer to as payload-id for
> now)? The difference seems to be between whether or not the payload-id can
> also be used as an address endpoint. I believe we can solve this
> problem by
> putting structure on the BTP URIs.

We are agreed that we should use URI at identification level (the
payload-id).

But I don't agree to using URI's at addressing level. Depending on details,
it loses flexibility, imposes complexity or is just a syntactic tweak. But
I'll hold that as secondary issue for now.

suggestion to clarify terms: on re-reading the first paragraph in rfc 2396
1.2, one finds that the URN and URL definitions actually depend on their
use, not their internal syntax. So, to take a particular
http://www.w3.org/2001/XMLSchema is a URN when it is used in an XML schema
(as Alex has just given us : ...    xmlns="http://www.w3.org/2001/XMLSchema"
... ) but a URL when you put in your browser. And it even identifies
different things, since the resource at web address is not a copy of the
schema but a page about (and linking to) a copy of the schema, but used as a
URN refers to the schema itself, as an abstract entity - whereever located
(the URN names one thing, which has multiple concrete representations)

> So, if we assume that everything is a URI then we are free to define these
> in our own format. Let's say that we assign URIs of type A to
> mean "I can be
> used as an address and an identifier" and URIs of type B to mean
> "I can only
> be used as an address".

so type A is "is a URL and a URN", type B "is a URL, not a URN"
there is also type C, "is a URN, not a URL" (can only be uses as an
identifier)

>            Now, we then say that all payloads that
> require what
> you would consider to be identifiers and addresses contain URIs for
> identification and optional URIs for addressing. If the URI a sender uses
> for payload-id is of type A then no other information need appear in the
> payload. However, if it is of type B then additional information
> must appear
> in the payload.

I don't think that last sentence is what you meant, or your defintion of
type B was what I've called C. I think you meant:

"If it [the payload-id] is of type C [i.e. is an identifier only ] then
additional information must appear in the payload [ i.e. at least one of the
optional addressing URIs must be present ]"

( as written it said "if the id used for identification can't be used for
identification, you must have extra information for addressing")

> In this way, an application that runs in an environment that knows
> payload-ids can always unambiguously refer to the end-point service can
> avoid sending additional information. Other application environments can
> suitably enhance the payload.

Questions:
are your "optional URIs for addressing" used for identification in any
circumstances ?  (i.e. are they specified as being URNs for the (same)
identified thing as payload-id identifies, as well as URLs)

are you using "end-point" as Jim was, to mean the specific object (sensu
latu) that is concerned with a single transaction/inferior, or can it be
something that has access/responsibility for multiple transactions ?

Is the determination that a particular URI in a payload-id is type A or type
C (i.e. whether or not it can be used for addressing) on the basis of the
"application environment", or on the basis of some part of the URI itself ?

Does "putting structure on the BTP URIs" mean defining one or several BTP
URI schemes ? [perhaps best clarified by example - what URI scheme(s) would
you expect for payload-id and "optional URIs for addressing" where the
binding was the soap-http-1 that we have in the spec, when used in the
"common", interoperable way? )

This was just clarification.  More later

Peter



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC