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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: RE: [Fwd: Re: [xacml] url/uri-string-concatenate]

Related question:

We do not support declaring base-uri property, do we?


-----Original Message-----
From: seth proctor [mailto:Seth.Proctor@sun.com] 
Sent: Friday, June 16, 2006 12:49 PM
To: Ron Williams
Cc: Anne.Anderson@sun.com; OASIS XACML TC
Subject: Re: [Fwd: Re: [xacml] url/uri-string-concatenate]

Ron Williams wrote:
> My inclination is to preserve the uri semantics for uri objects. I
> the use of string semantics likely to cause more inadvertent errors
> one might expect from the more restrictive uri constraints.

The thing is that these aren't URI semantics. They're URL or URN 
semantics. It gets complicated pretty quickly trying to figure out how 
you stitch things together.

For instance, the default URL scheme might be to always use "/" between 
each string. But, what if I have "http://example.com/cgi-bin"; and "foo" 
as my two inputs? Now I don't want a "/" used to connect these strings, 
but a "?" (etc.) instead. Or, what about "...name=" and "seth". There's 
no easy way to handle these cases separately.

So, is the common case that we want these components connected as-is, or

  based on the URI scheme that's being used? I'm not sure I know the 
answer, since very few people have given feedback about how this would 
get used in policies. I do know that strings are simple to work with, 
and will ultimately support a more flexible set of functionality. Based 
on this, and the fact that string semantics are what was originally 
defined, I think that's the best thing to use for now.


To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

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