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: [bt-spec] Proposal to resolve URI issue


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

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.

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". 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.

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.

Mark.

----------------------------------------------
Dr. Mark Little (mark_little@hp.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2606216
Fax   +44 191 2606250





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


Powered by eList eXpress LLC