[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss-x] Regarding DSS core schema
Sorry for jumping a bit late in the thread...two remarks:1. Regarding the cardinality, it is true that beign an attribute its cardinality can only be one...but the core defines the common optinal input (for both the sign and the verify protocols) AdditionalProfile, which makes it possible to build up requests/responses that are conformant to more than one profile.
2. Regarding the mandatory/optional, I think that the issue is a bit more confussing if we look clause 3.2 <SignResponse>... in this clause the Profile attribute inherited from ResponseBaseType, appears as [Optional]....so there is inconsistency between the derived type and its supertype...not in the xml schema (and this should be the reason why Andrea got that error result) but at the level of the textual specification....By the way, other than this [Required] versus [Optional], the rest of the text devoted to this attribute is the same in both 2.10 and 3.2.....
Regards Juan Carlos. El 18/01/13 10:15, Andreas Kuehne escribió:
Hi Stefan,thanks for adding the validator. I am curious, if I could somehow have a look at it or its sources ... :-?)it's build on top of the Apache Cocoon framework. This is based on Java, but the major programming work is done in xslt. And here the work of the TAML perfectly fits in, as it is done in xslt, too. But it may need some time to get used to this environment. Our work is open source, generally. But the current state isn't publicly available, yet. Major refactoring underway to fit into the Java repository world ... Maybe we could meet in Bonn and we could walk thru the major building blocks?With respect to your finding: In retrospect some differences between elements appear to be inconsistencies. We will have to look. Maybe there was a clever idea of one of the cooks involved when we prepared that meal in the years before 2007 ;-) I like to amend your question with the following: As a ResponseBaseType[2] in dss version 1 makes sense, if and only if a RequestBaseType[1] has been instantiated, it looks a bit misaligned, that the client may optionally set a Profile attribute on the element based on RequestBaseType he is sending, but the server is required to set a Profile attribute inside the corresponding response element derived from ResponseBaseType. Also since the type of the attribute in both cases is xs:anyURI the cardinality is fixed to one. I sguugest, that we SHOULD investigate by digging through the mail archives and our minds what lead us there and how we SHOULD proceed.Ok, let's start our new profession as standards archaeologist :-) I would guess it's ten years back when we designed these foundations of our structures ... Greetings, AndreasReferences: [1]: "2.10 Type <RequestBaseType>", http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html#_Toc157225013 [2]: "2.11 Type <ResponseBaseType>", http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html#_Toc157225014 All the best, Stefan.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]