Re: xml:id and opacity of refp's

The problem is defining what we mean by that ("ref props are anyhting but
opaque"). Opaqueness as an operating principle is important to protect
service requester interoperability. Requesters that start making their own
assumptions about ref. props. are setting themselves for a nasty surprise
when the server decides it needs to issue a different EPR for those
clients. In this sense, maintaining the opacity principle is very
important.

A different thing is whether people will treat EPRs as they treat URIs,
sometimes assuming an encoding pattern - which is essentially an extension
of the requester-provider contract. Nothing in the spec prevents that
today.

As for the ID problem, Jonathan pointed out already that this problem
exists whenever xml fragments are embedded into XML documents, and is not
an exclusive WS-Addressing problem.

Paco




                                                                                                                                               
                      Marc Hadley                                                                                                              
                      <Marc.Hadley@Sun.COM>           To:       Rich Salz <rsalz@datapower.com>                                                
                      Sent by:                        cc:       public-ws-addressing@w3.org                                                    
                      public-ws-addressing-req        Subject:  Re: xml:id and opacity of refp's                                               
                      uest@w3.org                                                                                                              
                                                                                                                                               
                                                                                                                                               
                      01/05/2005 04:18 PM                                                                                                      
                                                                                                                                               





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.

Received on Wednesday, 5 January 2005 21:37:59 UTC