[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss-x] self-describing DSS-X instances
To fast... XML Schema validation does not accept the redefined XML schema: Schema schema = schemaFactory.newSchema(schemaSource); Validator validator = schema.newValidator(); validator.validate(new DOMSource(document)); gives me:Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.132 sec <<< FAILURE! testXMLGeneration(org.oasis.dssx.dss.XMLTest) Time elapsed: 0.131 sec <<< ERROR! org.xml.sax.SAXParseException; lineNumber: 9; columnNumber: 119; src-import.1.1: The namespace attribute 'urn:oasis:names:tc:dss:1.0:core:schema' of an <import> element information item must not be the same as the targetNamespace of the schema it exists in. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)
Anyone a working example for this??? Kind Regards, Frank. On 01/29/2018 05:47 PM, Frank Cornelis wrote:
Resending to the group... On 01/29/2018 05:46 PM, Frank Cornelis wrote:Hi Andreas,It took me a while to construct a working example of such extension that could be referenced within a WSDL.Example extension dss-example-extension.xsd: <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema" xmlns:dsb="urn:oasis:names:tc:dss:2.0:base:schema" targetNamespace="urn:dss:myextension" xmlns:my="urn:dss:myextension"elementFormDefault="qualified" attributeFormDefault="unqualified"><xs:group name="mygroup"> <xs:choice> <xs:element name="Test" type="my:TestType"/> </xs:choice> </xs:group> <xs:complexType name="TestType"> <xs:sequence> <xs:element name="Value" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:schema>And then I needed a second XML schema just to redefine the DSS element _within the same DSS namespace_: dss-example-extension-redefine.xsd:<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema" xmlns:dsb="urn:oasis:names:tc:dss:2.0:base:schema" targetNamespace="urn:oasis:names:tc:dss:1.0:core:schema" xmlns:my="urn:dss:myextension"elementFormDefault="qualified" attributeFormDefault="unqualified"><xs:import namespace="urn:oasis:names:tc:dss:1.0:core:schema" schemaLocation="oasis-dss-core-schema-v1.0-os.xsd"/><xs:import namespace="urn:oasis:names:tc:dss:2.0:base:schema" schemaLocation="oasis-dss-base-schema-v2.0-os.xsd"/><xs:import namespace="urn:dss:myextension" schemaLocation="dss-example-extension.xsd"/><xs:redefine schemaLocation="oasis-dss-core-schema-v1.0-os.xsd"> <xs:complexType name="OptionalInputsSignType"> <xs:complexContent> <xs:extension base="dss:OptionalInputsSignType"> <xs:group ref="my:mygroup"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:redefine> </xs:schema> Which I can import within my WSDL via: <types> <schema xmlns="http://www.w3.org/2001/XMLSchema"> <import namespace="urn:oasis:names:tc:dss:1.0:core:schema" schemaLocation="dss-example-extension-redefine.xsd" /> </schema> </types>I still get a warning during compilation, but at least it compiles and seems to work at runtime:src-import.1.1: The namespace attribute 'urn:oasis:names:tc:dss:1.0:core:schema' of an <import> element information item must not be the same as the targetNamespace of the schema it exists in. line 9 of file:/home/fcorneli/dss-x/src/wsdl/dss-example-extension-redefine.xsdStill some points I worry about:* this adds yet another getter that I have to check within my server-side implementation (already at 16 on the vanilla DSS Core 2).* this "single inheritance" mechanism allows only one profile -in a clean way- at the same time. If you want to use -say 5 profiles- you have to create the "intermix" top-redefine XML schema yourself. This could become very ugly after a while I guess...Of course I don't expect that an XML parser can parse ASN.1/DER, else it wouldn't be called an XML parser in the first place. :)But you surely won't complain that there is a distinct parsing step to read a X.509 certificate within an XML message.However, I do expect my XML parser to parse my XML.This comes with thedis-advantage but avoids inter-dependencies between architectural layers.OK, I lost you here. What do you mean? Kind Regards, Frank. On 01/29/2018 03:49 PM, Andreas Kuehne wrote:Hi Frank, let me explain my view on the 'extension' mechanism: To me the use of an xs:any as a way to extend a given schema is more a flaw than a feature. The implementor of the spec is left on his own parsing something unknown and trying to make sense of it. No schema-generated object models helps along and all types of interpretation problems show up an runtime! As we write a specification we MUST specify the structure!So my approach to this flexibility problem is to create specific schemesincluding all elements. This eases the implementation of clients a lot and puts just a little more effort upon the server. In your case it is perfectly valid to define a profile that adds a ds:signature element into the OptionalInputs. And the server offers aWSDL refereing to a scheme where this ds:signature element is explicitlymentioned in the OptionalInputs. Nevertheless we came to the conclusion that directly embedding a ds:signature into the SOAP / DSSRequest message isn't a good idea due to namespace leakage and canonicalization side effects. BAse64 encoding eases the pain here. So I strongly reject the need for 'alien' namespace inclusions. Thenamespaces must all be known. And this isn't a restriction as sender andreceiver are obliged to know them, anyway! Yes, the overall amount of parsing may increase. But you surely won't complain that there is a distinct parsing step to read a X.509certificate within an XML message. Now there are some additional parsingrequired for XML within XML. This is a disadvantage but it enables a clear distinction between the 'DSS object model' and the different transport syntaxes. The processing of a request should be the same regardless of the usage of XML, JSON or whatever. E.G a XAdES object will be transferred in the same manner, always. And can be accessed at the same spot in the object model, always. This comes with thedis-advantage but avoids inter-dependencies between architectural layers.Therefore the UBL approach of 'any' representations in different syntaxes helps with our problem: A semantic 'any' may hold any content,but a XML any is limited to XML, a JSON 'object' limited to JSON, and soforth. Greetings, AndreasHi, As one of the goals of DSS 2 is "Support other transport formats than SOAP.", message-level security becomes a critical feature I guess. SOAP security is covered by WS-Security/WS-SecurityPolicy and such. A non-SOAP binding requires message-level security, obviously by means of XML signatures. I did some more experiments with message-level security. While this could be added in DSS 1, see: https://www.e-contract.be/sites/dssp/dssp-specs/dssp-specs-1.5.1.pdf section 2.2 Browser POST, due to the AnyType being a base64 in Core 2: <dss:SignRequest xmlns:dsb="urn:oasis:names:tc:dss:2.0:base:schema" xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <dss:OptionalInputs> <dsb:Other> <dsb:Value>d2hlcmUgZG8gSSBwdXQgbXkgWE1MIHNpZ25hdHVyZT8=</dsb:Value> </dsb:Other> </dss:OptionalInputs> </dss:SignRequest> it becomes impossible to express this. XML Signatures work at the DOM level, so we really need to be able to add "alien-namespace" XML elements. Besides the XML Signature issue, the parsing of additional profiles becomes a two-pass operation. In Core 1, you could add your additional profiles within your WSDL by means of a simple import. See example: https://www.e-contract.be/sites/dssp/dssp-specs/dssp-ws.wsdl Feeding this to JAXWS/JAXB made it possible for JAXB to actually parse your additional profiles in one go. With the Core 2, you parse a first time towards base64, and then you have to run a second JAXB unmarshalling against this. From a usability/performance point-of-view, this becomes really painful.The structures intended to be supported by a client or a server system MUST be known to be implementable. But the usual tools for schema support leave the task of handling the content of an any type to the developer. Without extensive testing problems with unexpected content may occur at runtime, even while using typed languages.An AnyType of unknown namespace (in the context of the parser like JAWS/JAXB) simply results in a DOM element, as it should be. I don't see the problem here. Even if one would acknowledge this as a problem, doing a base64 is not solving anything at all. The problem remains. What am I missing here? I'm already managed to use Jackson for JSON Schema compilation in Java. Will play a bit with this AnyType stuff to see if the above issues could be resolved in a generic way to keep both XML and JSON happy. Kind Regards, Frank. On 01/28/2018 12:16 PM, Frank Cornelis wrote:Hi Andreas, Still have to get acquainted with the JSON Schema specs/tooling, but it seems like OASIS UBL solved a similar problem where both their XML and JSON have extension points, and their XML does it via xsd:any. See:http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.1/csprd01/Business-Document-NDR-v1.1-csprd01.html#S-EXTENSION-XML-SCHEMA-FRAGMENTS-AND-DECLARATIONSAnd:http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.1/csprd01/Business-Document-NDR-v1.1-csprd01.html#S-EXTENSION-JSON-SCHEMA-FRAGMENTS-AND-DECLARATIONSBTW: In my “sandbox” project here, as part of my message-level security experiments, I also had to give the new Core 2 XSD a 2.0 namespace to be able to compile both Core 1 and Core 2 within the same Java Maven project. Core 2 will eventually receive a new namespace I guess? Kind Regards, Frank.Op 26 jan. 2018, om 19:47 heeft Andreas Kühne <kuehne@trustable.de <mailto:kuehne@trustable.de>> het volgende geschreven: Hi Frank, thank you for your feedback! Yes, it’s an advantage to provide a sample WSDL as implementor’s support. But due to the support of current frameworks the WSDL slides towards being a derived artefact. I was assuming that the binding and the ‘annox’ namespaces, leaking thru from prior processing steps, are just irrelevant here. Interesting to see that these declarations do cause problems. Now I’ll drop them before reaching the final schema stage. Surprisingly no way to drop namespace declarations that are defined in the incoming document using XSLT … had to fall back to RegEx. Regarding the AnyType: The handy use case of putting some random XML fragment into an AnyType cannot be supported by the JSON syntax and vice versa. So the only feasible approach to transport arbitrary data _/and/_ supporting multiple syntaxes is to use some base64 encoded container. And we already have a fully featured Base64DataType defined in DSS (with a content describing MIME type attribute, support for references and attachments). So why not align all usages to the Base64DataType? The biggest pain point of the current multi-syntax approach is the effect on foreign schemes. As outlined in the new core draft, section 2.6, some well-respected features of XML cannot easily be mapped to e.g. JSON. So my current approach is to rewrite the referenced schemes and replace the XML specifics. Yes, bad approach but I don’t know of any better! Proposals welcome! Greetings, Andreas *Von:*dss-x@lists.oasis-open.org <mailto:dss-x@lists.oasis-open.org> [mailto:dss-x@lists.oasis-open.org]*Im Auftrag von*Frank Cornelis *Gesendet:*Freitag, 26. Januar 2018 15:16 *An:*dss-x@lists.oasis-open.org <mailto:dss-x@lists.oasis-open.org> *Betreff:*Re: [dss-x] self-describing DSS-X instances Hi Andreas, Hereby some feedback on the XML schema and such. Why change AnyType exactly? Kind Regards, Frank. OASIS DSS Core 2 Remarks ======================== xml.xsd is missing from the ZIP. Always found it funny that there was no proper SOAP binding defined. See attachment for a first shot at it. === oasis-dss-core-schema-v1.0-os.xsd When trying to compile with JAX-WS I get: org.xml.sax.SAXParseException;systemId:file:/home/fcorneli/dssp-2/src/wsdl/oasis-dss-core-schema-v1.0-os.xsd <file://home/fcorneli/dssp-2/src/wsdl/oasis-dss-core-schema-v1.0-os.xsd>;lineNumber: 1; columnNumber: 703; Unsupported binding namespace"http://annox.dev.java.net" <http://annox.dev.java.net/>. Perhaps you meant"http://java.sun.com/xml/ns/jaxb/xjc" <http://java.sun.com/xml/ns/jaxb/xjc>? Had to remove: xmlns:annox="http://annox.dev.java.net" <http://annox.dev.java.net/> jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc" === oasis-dss-base-schema-v2.0-os.xsd Same error here: org.xml.sax.SAXParseException;systemId:file:/home/fcorneli/dssp-2/src/wsdl/oasis-dss-base-schema-v2.0-os.xsd <file://home/fcorneli/dssp-2/src/wsdl/oasis-dss-base-schema-v2.0-os.xsd>;lineNumber: 1; columnNumber: 555; Unsupported binding namespace"http://annox.dev.java.net" <http://annox.dev.java.net/>. Perhaps you meant"http://java.sun.com/xml/ns/jaxb/xjc" <http://java.sun.com/xml/ns/jaxb/xjc>? So had to remove: xmlns:annox="http://annox.dev.java.net" <http://annox.dev.java.net/> jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc" === xmldsig-core-schema.xsd This does not seem to be the original XMLDSig XML schema. Same error here: org.xml.sax.SAXParseException; systemId:file:/home/fcorneli/dssp-2/src/wsdl/xmldsig-core-schema.xsd <file://home/fcorneli/dssp-2/src/wsdl/xmldsig-core-schema.xsd>; lineNumber: 23; columnNumber: 579; Unsupported binding namespace"http://annox.dev.java.net" <http://annox.dev.java.net/>. Perhaps you meant"http://java.sun.com/xml/ns/jaxb/xjc" <http://java.sun.com/xml/ns/jaxb/xjc>? So had to remove: xmlns:annox="http://annox.dev.java.net" <http://annox.dev.java.net/> jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc" === oasis-sstc-saml-schema-protocol-1.1.xsd This does not seem to be the original SAML 1.1 XML schema. org.xml.sax.SAXParseException;systemId:file:/home/fcorneli/dssp-2/src/wsdl/oasis-sstc-saml-schema-protocol-1.1.xsd <file://home/fcorneli/dssp-2/src/wsdl/oasis-sstc-saml-schema-protocol-1.1.xsd>;lineNumber: 1; columnNumber: 705; Unsupported binding namespace"http://annox.dev.java.net" <http://annox.dev.java.net/>. Perhaps you meant"http://java.sun.com/xml/ns/jaxb/xjc" <http://java.sun.com/xml/ns/jaxb/xjc>? So had to remove: xmlns:annox="http://annox.dev.java.net" <http://annox.dev.java.net/> jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc" On 01/24/2018 03:49 PM, Andreas Kuehne wrote:Hi Frank, good to see you re-joined DSS-X! Attached id the current core document reflecting our latest discussions regarding the dss:AnyType. In this version the AnyType is replaced by a Base64DataType. As you are interested in Remote Signing I added the schema of the ChipGateway profile, too. Greetings, AndreasHi Andreas, Were can I find the 2.0 XML schema? I would like to check whether a "Remote Signature" profile with message-level integrity protection could be easily defined against the new 2.0 proposal. Kind Regards, Frank. On 01/24/2018 12:47 PM, Andreas Kuehne wrote:Hi all,the current version of the base schema includes a set of types to toself-decribe the DSS-X server instance (e.g. the DescriptionType). There are similiar concepts around, a popular one is HATEOS. So I would consider to separate this topic from the DSS-X specification. Like the TLS details included in core version 1.0 that outdated quickly the evolving area of instance meta information may render our specification effort useless. What's your view on this? Greetings, Andreas--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC thatgenerates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php-- Frank Cornelis e-Contract.be <http://e-Contract.be> BVBA https://www.e-contract.be <https://www.e-contract.be/>
-- Frank Cornelis e-Contract.be BVBA https://www.e-contract.be
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]