RE: xbinc:Include and identity

 

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of Marc Hadley
> Sent: 08 May 2003 17:34
> To: Jeffrey Schlimmer
> Cc: xml-dist-app@w3.org
> Subject: Re: xbinc:Include and identity
> 
> 
<SNIP/>
> > That invites the question: if we make this assumption, how does one 
> > reference content from within > 1 place within the Envelope? One 
> > approach is to have a named place within the Infoset where 
> the content 
> > is included, and have the other places within the Envelope refer to 
> > (ala xs:anyURI, not include) that place. The Representation 
> element in 
> > PASWA does this. This approach addresses concerns about on-the-wire 
> > efficiency as well as concerns about modeling shared 
> identity within 
> > the Infoset.
> >
> Yes, but it raises other questions.
> 
> 1) I'd like to be able to generate data binding code from 
> message schema. The proposed xmime:Binary type lets me 
> generate suitable mappings for the single place where the 
> data is included but doesn't cover the situation where I have 
> multiple references to the data. The current formulation 
> suggests use of an application specific referencing mechanism 
> for each additional reference to the binary data, a 
> standardized xmime:BinaryRef type would be more useful for 
> tooling purposes and would also allow for better verification 
> of references on message receipt.

Given that you have a schema for the message, you know which
elements/attribute are URIs. Would it not make sense therefore to turn
the xbinc:Include parent into an object representation of the
attachment, say Gudge.MimeTypes.Images.PNG and then have the URIs that
refer to that just be untyped references?

> 
> 2) The semantics of message security in the presence on 
> Include and references needs to be carefully considered. If I 
> sign part of a message containing an xbinc:Include then I 
> probably want to sign the actual data rather than the Include 
> EII itself. 

Yes, I would think the date should be signed. This raises a potential
security concern; how do I sign the href attribute on the xbinc:Include
( so that no-one can change the value of that attribute ). However,
enforcing xbinc:Include/@href to resolve to something inside the package
and signing the data would mitigate that attack.

> If I sign part of a message that includes 
> references to representation elements then presumably I'm 
> only signing the reference, not the referenced data ?

Yes, if I have j:RandomElement/@href and I sign that, I'm signing the
reference. I would also need to sign the swa:Representation header
element to ensure no one tampered with the data

Does this make sense?

Gudge

Received on Wednesday, 14 May 2003 11:17:22 UTC