[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] XMLData problem in Core "Opaqueness
Thanks Conrad,
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.
Ed
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 To: ed.shallow@rogers.com Cc: 'Juan Carlos Cruellas'; 'OASIS DSS TC' Subject: Re: [dss] XMLData problem in Core "Opaqueness please see below. Konrad 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 context. (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 remains. 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..... |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]