Re: xml:id and opacity of refp's

On Jan 5, 2005, at 4:37 PM, Francisco Curbera wrote:

>
> The problem is defining what we mean by that ("ref props are anyhting 
> but
> opaque").

Actually I think the problem is our current claim that refps are opaque 
;-). Its clear from several problems that have surfaced that refps are 
not opaque, a user of an EPR needs some knowledge of their structure to 
avoid constructing messages that are invalid in one or more ways.

>  Opaqueness as an operating principle is important to protect
> service requester interoperability.

I agree that it would be desirable, I'm just pointing out that it has 
not been achieved. This is a difficult problem to solve when a 
recipient is required to include an XML fragment verbatim in their 
messages and, IMO, is made worse when that XML fragment is required to 
be a SOAP header.

>  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.
>
Can you give me an example of what you mean by the above ? Here's a 
counter example: I have an EPR with a refp whose QName I happen to 
understand. I know that the 'serviceId' attribute of the root element 
of the refp is of type id so I make sure not to create any other ids 
with the same value in messages I send to that EPR. What problem am I 
causing by taking advantage of my understanding of the refp structure ?

Perhaps we mean different things by opaque. For me it implies that I 
don't need to know anything about the contents to use it successfully 
(like a HTTP cookie).

Marc.

> 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.
>
>
>
>
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Wednesday, 5 January 2005 21:58:51 UTC