Re: xml:id and opacity of refp's

The lack of opacity has also emerged on other threads (e.g. [1]). I 
think we need to accept that refps are anything but opaque in any real 
sense of the word.

Marc.

[1] http://www.w3.org/mid/684C1D92-3CB9-11D9-B7E8-000A95BC8D92@Sun.COM

On Dec 21, 2004, at 7:15 PM, Rich Salz wrote:

>
> Dims posted a message ("just thinking out loud here...") that included 
> a
> snippet of an EPR with a DSIG in it.  It just brought to mind an issue.
>
> One of XML's validity constraints is that attributes of type ID have
> unique values.  In order to not generate invalid XML, a program that 
> uses
> the refp's from an EPR must scan them to make sure that the ID 
> attributes
> that *it* generates are unique.  This violates opacity, but without 
> that
> violation a client cannot be sure of generating valid messages.
>
> Further, while xml:id is useful, there are still many ID attributes in
> other namespaces.  This requires even deeper knowledge and inspection
> by the EPR recipient, further ripping away opacity.  It's a hard 
> problem,
> of course, since there is no guarantee that the EPR recipient will even
> *know* what the ID attributes are inside a refp.
>
> Short of probabilistic values for ID attributes (viz., MIME separators 
> for
> multipart), opacity must be broken.
> 	/r$
> -- 
> Rich Salz                  Chief Security Architect
> DataPower Technology       http://www.datapower.com
> XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
> XML Security Overview      
> http://www.datapower.com/xmldev/xmlsecurity.html
>
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.