

RE: ISSUE-10: Mappings - proposed text

From: <jon.calladine@bt.com>
Date: Tue, 5 Sep 2006 15:35:16 +0100
Message-ID: <657E2B34242ACC46BDD6774A9728F9E3010DCD81@E03MVZ3-UKDY.domain1.systemhost.net>

Here is the text as discussed on the call.

Design Consideration.

The naming of element and type names remains a problematic area for
databinding tools. As the fundamental building blocks of an xml
document, tools *should* be able to support *any* valid XML element
name. This is still not the case however.

Historically, early versions of tools would not cope with the more
unusual characters available to the schema author, and these tools would
refuse to generate code. In all modern tools we have experience of there
is now excellent coverage of xml element names in so far as databinding
tools will generate the necessary serialisation/deserialisation code.
That this remains a problem area is to do with the mapping of valid xml
names to programming language specific environments often resulting in
'unpalatable' translations.

In many tools (but not all) it is possible to manually map the names to
something that is more acceptable to the developers but it must be
emphasised this is a manual step and will be very much dependent on the
specific programming language being used.

We have stopped short of giving language specific guidelines in this
basic patterns document because our aim is to provide generic guidance
to the schema author on what will work well. Our approach in this area
is as follows.

Where any character other than US ASCII is used in a schema document the
basic patterns validation rules will generate a *single* Information
message as follows:

Information: Element names in the schema have been constructed using
characters that will not map directly into all programming language
character sets for variables. The use of these element names will not
prevent databinding tools from generating mappings for these names but
the mapped names may not be 'meaningful' to the developer or may require
a manual reconfiguration of the code to make it so. For ultimate
interoperability use only US ASCII character set.
Received on Tuesday, 5 September 2006 14:36:12 GMT
