[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Rewriting of imported schemes
Hi all, as agreed on the last call I did some research regarding the volume of imported structures. XMLDSig & SAML: The blobification of signatures and timestamps in the core limits the core's references to external types significantly. There are the SAML schemes and XMLDSig. The latter provides especially CanonicalizationMethodType and TransformType. Both contain all major non-XML-syntax incompatibilities: xs:any, mixed content and a XPath expression. The 're-creation' of these types in a compatible way within DSS-X core could be an option. The same is true for SAML. XAdES: Considering the AdES or the Verification profile the XAdES schema is included. It contains many structures and types that do not fit into the multi-syntax approach. It even defines the most evil AnyType (sequence of xs:any and mixed content and an arbitrary set of attributes). It also makes intensive use of the '<xs:choice maxOccurs="unbounded">' pattern that does not fit very well with Java's schema-to-code compiler. This pattern produces non-typesafe code like an xs:any. So the version 2.0 design goals cannot be achieved with an unmodified XAdES schema. A quick check with the code coverage of my DSS-X tests shows that at least 50% (25 out of 50) of the structures defined in XAdES are used so cherrypicking of the 'useful few' does not work out. Applying the blobification approach to the verification report sounds promising for the verification report if it will restricted to be 'XML-syntax only'. This could be acceptable and the JSON syntax problem do not apply. But the verification report itself is not a autonomous artifact but uses the core schema. So we would introduce a mix of multi-syntax-enabled types and XML-only parts. To me this sounds like a concept that wiil be hard to understand for any DSS-X user. My recommendation would be to keep things easy to use and consistent: Support the multi-syntax paradigm everywhere and don't introduce XML-only profiles! But this comes with price of rewriting of external schemes. Let's see what's Peter's view on JSON support for the verification report. I wouldn't be surprised that team working with Javascript in the browser and / or node.js in the server side would appreciate to see a verification report in JSON. Greetings, Andreas -- Andreas Kühne phone: +49 177 293 24 97 mailto: kuehne@trustable.de Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612 Director Andreas Kühne Company UK Company No: 5218868 Registered in England and Wales
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]