OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: AW: [dss-x] Some feedback on the core 2.0 document

Hi Ernst Jan,

I'm a bit torn between pros and cons of extensibility here! Flexible container are handy for sure, but the other hand we are defining an interface contract that MUST be understood by both parties! We should not assume a bilateral agreement between the communicating parties. OK, that may be true for remote signing use cases with servers and apps from the same vendor ... but in case of verification and time stamping services this cannot be assumed. So I would tend to drop extension points. A special purpose protocol can derive it's schema from DSS and add well-defined elements.  

Regarding formal language:
I'm a bit astound that there is no 'prior art' available! We are definitely not the first group trying to specify something intended for multiple transports. Even within OASIS there are lots of SOAP/JSON pairs defined! Do I miss some obvious?

If we really have to start from scratch: I would start with a stripped-down version of XML schema due to the maturity of XML schema and the available tools for XML processing able to produce text, JSON and XML output. The latter could be a docx-fragment! So we could circumvent nasty and error prone schema snippet processing! I'll take a look at it to check whether this is a feasible approach.


-----Ursprüngliche Nachricht-----
Von: dss-x@lists.oasis-open.org [mailto:dss-x@lists.oasis-open.org] Im Auftrag von Ernst Jan van Nigtevecht
Gesendet: 07 July 2017 08:53
An: dss-x@lists.oasis-open.org
Betreff: Re: [dss-x] Some feedback on the core 2.0 document

Hi Andreas,

The ContainerType is intended for encapsulating 'any' future structures/components ('The ContainerType is a composite data type that can contain an arbitrary number of components'). But I must admit that the current 'formal' description may be a bit weak.

I agree with you that we have to find some formal language; at the same time, the formal language should not be too complicated :-)

At the moment the Remote Signing profile document does not use a formal generic language...


Ernst Jan

Andreas Kuehne wrote:
> Hi Ernst Jan,
>> Please find attached some feedback on 
>> "dss-core-v2.0-wd01-2016-06-26.docx". (I have used LibreOffice, they 
>> layout is a bit ruined, so don't use it further!!).
>> ** I have made pdf versions of the pages that I have changed. I did 
>> not yet go through the whole document (it's a lot!)... **
>> Hope it helps a bit in separating the generic semantics and specific 
>> mappings to xml or json.
> sorry, but I'm afraid I didn't get the 'ContainerType' approach right.
> Is it a generic base type of all types holding sub-elements?
> Moreover the current approach to define structures normatively using 
> common language and later on do a manual mapping to different schema 
> formats seems work intense, error prone, unmaintainable and hard to 
> comprehend for a reader. I would prefer some type of 'central' formal 
> language and derive the common language description and the specific 
> schemes from it.
> Do you do something similar with the Remote Signing profile document?
> Greetings,
> Andreas

To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]