[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.) Eve 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 >fragments. > >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 >http://foo.bar/base/PKCS7 >style I used. > >This would also change RespondWith slightly so that the identifiers were all >nominaly >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 >spots. -- 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