Re: [dss-x] XML & JSON name mapping irritations

[Ernst Jan van Nigtevecht <EJvN@Sonnenglanz.net>]

Very nice! In section on the semantic 4.1.6. I see the use of IDREF

·       This identifier gives the binary data a unique label within a particular message. Using this identifier and the IDREF element it is possible to avoid redundant content.

I would expect

·       This identifier gives the binary data a unique label within a particular message. Using this identifier and the IdRef element it is possible to avoid redundant content.

Because the next paragraph also uses IdRef as well as the XML part

The elements ‘Id’ and ‘IdRef’ have slightly different names (‘ID’ and ‘IDREF’) within XML syntax to match the XML schema standards for unique identifiers and their reference.

When I scan the text, I noticed in 4.2.2.1 the use (in the semantics part) of ID and IDREF. Should this be changed into Id and IdRef (for consistency)?

Regarding the CamelCase, what about the RequestID , ResponseID?  (4.1.10.1) Yeah, it's minor... :-)  But regarding consistency ..  :-)

Regarding the introduction of operations, it would be good to have a sentence that refers to the main (root) elements of the model (in the introductory section 5) like the SignRequest and SignResponse, etc. (and the representative terms in XML and JSON in the other sections). Similar to the sentence in 4.2.6.1 The SignRequest component is sent by the client to request a signature or timestamp on some input documents. From a different perspective: "if the reader would start at section 5, is the reader able to identify the main/starting elements, so that the reader can easily find the right components in section 4?"

The additional grouping, 4.1, 4.2, 4.3, is ok;  I think that additional groupings/sections will not help much (the grouping in itself can become complex as well because the number of elements and options is huge in itself). Maybe a grouping with elements that are only used by Request operations, elements that are only used by Response elements and elements that are used in both? But I don't know if that really helps (especially if there are too many common elements:-) . Maybe if the reader wants to 'process' section 4 with a 'Request' in mind. But than Section 5 should be the starting point... If the reader wants to know where to start and what to use (and when) I think that the reader has to go to section 5 :-)

Regards

Ernst Jan

Andreas Kuehne wrote:

Hi Ernst Jan,

thank you for your quick (and positive) response! Freshly motivated I
addressed the other topics of our last call (see recent version attached):

Decouple names in semantic model and XML syntax:
As far as I understood there is currently only the ID & IDREF elements
in Base64Data that does not match the CamelCase naming scheme. So I
introduced the option to specify a 'modelName' attribute to each element
if it deviates from the XML name. For just these two elements I did not
introduce an programmatic handling but added a sentence into the 'XML
syntax' section comment. See section 4.1.6 & 4.1.6.2

Making 'operations' more explicit:
With the given 'feature' of arbitrary grouping I introduced a new
'operation' group and added a bitr opx explanatory comment to this new
section (4.2.). Is this a useful way to proceed or do we need additional
mechanisms /restructurings? 


Greetings,

Andreas