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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: Re: [security-services] URI extensions etc

I must have missed this discussion; what was the benefit claimed for this 
approach?  (I'm not necessarily against it.)

This approach points up the importance of talking about URI *references* in 
the text, not just URIs.  I think I've commented on this before.  ("URI 
reference" means the URIs that are allowed to have have fragment 
identifiers on them.)  If we don't say we allow URI references, then 
fragment identifiers technically aren't allowed, though I doubt there's 
much software that would hold implementations to this restriction.

(I'm not too crazy about messing with base URIs; their semantics are a 
little tricky.  BTW, xml:base is one of those pseudo-native XML attributes 
that can't be validly used unless we really include it in our 
schema...  I'd rather have whole URI references be spelled out.)


At 05:46 PM 1/31/02 -0800, Hallam-Baker, Phillip wrote:
>One issue that was raised was the issue of expressing identifiers as URI
>I.E. if our base spec is http://foo.bar/base then the identifiers defined
>therein should
>be of the form http://foo.bar/base#X #Y #Z etc rather than the
>style I used.
>This would also change RespondWith slightly so that the identifiers were all
>fragments off the default URI which would be the base URI for the spec.
>All this means in practice is we introduce some # characters in several

Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com

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

Powered by eList eXpress LLC