Re: [dss-x] Regarding DSS core schema

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

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,
>
> Andreas
> > References:
> >
> >
> > [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.