[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