[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss-x] ID vs. Id vs. id, semantic and XML syntax, readability
Hi Andreas, sorry to hear there were problems via voice line. Love to see the flaw fixed :-)I prefer your efficient solution proposal and please provide a document coming out of it, so I can adapt the current CSD01 candidate master (which I will continue to prepare for publication whatever by hand
As with the second proposal, I am all for it whatever grouping is decided but would need a specific output to not remain blocked on these last meters of our prepublication sprint.
All the best, Stefan. Am 11.06.18 um 22:50 schrieb Andreas Kuehne:
Hi colleagues, due to restricted ausio abilities during the call I would comment on three topics within this mail: I have to admit that a sloppy assembly of the name mapping table introduced the irritating 'Id' entry. This element is defined in XMLDSig schema (in SignatureValueType) but it's not used in the core schema. But my simplistic creation of the names map takes all schemes and groups XML and JSON names. Shame on me, I'll fix this flaw. Regarding the topic of semantic vs syntax: I agree with Ernst Jan that the sematic model should be independent of any syntax. So I would consider it just a coincidence that the model names match the XML names quite good. But we discussed the few differences ( 'ID' et al) and the introduction of a model->XML mapping for every element seems to be an overkill. An efficient solution I would propose is : * Enrich the input scheme with XML-specific names ( es:xmlName="ID") when the model and XML names differ * Use camelCase Names (starting with an capital letter) in the semantic model * map the JSON names as usual * Add a specific comment to the XML section of the components where mapping is required. Like the automatically added comment regarding the synthetic 'value' member in the JSON mapping. * Extend the schema and specification generator This approach has a clear structure, and a proper separation of concerns. The current version of the documentation generator has already the ability to group the components by arbitrary tags. Section 4.2 groups all components associated to request/response. We can rearrange the components included in this section, or even create a new 'operation' section. What's your view on these topics? Greetings, Andreaas -- 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
-- Stefan Hagen read://shagen.de talk: eventually
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]