ID vs. Id vs. id, semantic and XML syntax, readability

Hi, regarding the topic of semantic vs syntax: sounds good to me!
Regarding the operations, I think we need a clear indication of the main documents and their purpose, similar to a root element in a message.
But I would not 'fix' it to a WSDL description structure, because that is also a transport aspect.
What if we want to use ebMS2 of AS4 or REST?
So, a description from a logical point of view is needed to indicate the main documents and actions/operations/processes, but it should be independent of a transport protocol.
Regards Ernst Jan Andreas Kuehne wrote: 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: 
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