Rewriting of imported schemes

[Andreas Kuehne <kuehne@trustable.de>]

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