[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] XMLData problem in Core "Opaqueness
I think you are agreeing with me in principle ? Not sure what you mean by
... and enclosed in tags similar to the <dss:XMLData> tags ...
Perhaps you could provide an example ? I was thinking more along the lines of additional <dss:Document> choices which are inherently more specific wrt encoding.
The problem with <dss:XMLData> is that it is of type AnyType and as such is too silent on potential use of encoding.
This makes it difficult to implement as there is no basis for infering content make-up which is my current dilemna.
P.S. I have got around the <Document> within <Document> problem should a user's payload contain a dss element. The "PI and declaration" lines is still a problem/challenge.
From: Konrad Lanz [mailto:Konrad.Lanz@iaik.tugraz.at]
Sent: April 8, 2005 5:59 AM
Cc: 'Juan Carlos Cruellas'; 'OASIS DSS TC'
Subject: Re: [dss] XMLData problem in Core "Opaqueness
please see below.
Edward Shallow wrote:
However I would advocate that everything that is xml and is to be transported in an opaque way(In fact DocumentBaseType could easily be extended to further collapse the excessive number of document/signature type elements we presently have i.e. Document, DocumentWithSignature, SignatureObject, UpdatedSignature, Timestamp, etc ...)
by the dss core protocol should be clearly identified as payload (or plain raw xml data if you want)
and enclosed in tags similar to the <dss:XMLData> tags to underline the required opaqueness.
This should be done in either direction for signing and verifying for request and response.
Hence this also applies to detached and enveloping signatures which are to be returned in a
<dss:SignatureObject> in a <dss:SignResponse> or <dss:VerifyRequest> and potentially
other forms of payload like <ds:Transforms> and <ds:KeyInfo>.
This further allows to use xml binding frameworks like JAXB to extract documents having
<dss:XMLData> as root element and it's child nodes can easily separated from the ancestry
(for a detailed explanation search for importNode in my last email 04 Apr 2005)
However the problem concerning the transport of certain processing instructions and xml declarations
please search for "get rid of the namespace context" in my last email 04 Apr 2005.Did not one of the public comments mention problems associated with unwanted namespace inheritance from parent nodes in the request ?So far we have not received any other comment about that...I think that maybe one of the things that we should do is to test this feature in the interop and leave it documented.....