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

[Andreas Kuehne <kuehne@trustable.de>]

Thank you, Ernst Jan!

Detailed review before I even had my first coffee!!
> 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.
Fixed.
>
> 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)?
Fixed.
> Regarding the CamelCase, what about the RequestID , ResponseID? 
> (4.1.10.1) Yeah, it's minor... :-)  But regarding consistency ..  :-)
I don't have any strong view on this. What's the opinon of the others
colleagues?
> 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 SignRequestcomponent 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?"
I'm not quite sure whether we can solve the problem of providing a
simple document with an easy top-down document without making forward
references or bury the reader in details before the big picture is
drawn. Maybe we should leave the structure as is and provide a simple
'beginner's guide' document.
> 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 :-)

I have to admit that I accidentally send an outdated version without the
proper regrouping. Please take a look at the document attached.

Greetings,

Andreas


> 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
>>
>>
>

-- 
Andreas Kühne 
phone: +49 177 293 24 97 
mailto: kuehne@trustable.de

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas Kühne

Company UK Company No: 5218868 Registered in England and Wales

Attachment: dss-core-v2.0-18.06.20_18.47.59.docx
Description: Binary data