W3C home > Mailing lists > Public > public-xsd-databinding@w3.org > May 2006

Proposed text for ISSUE-10 - Mapping Element and Type names

From: <paul.downey@bt.com>
Date: Tue, 2 May 2006 14:48:42 +0100
Message-ID: <2A7793353757DB4392DF4DFBBC95225504BFE953@I2KM11-UKBR.domain1.systemhost.net>
To: <public-xsd-databinding@w3.org>

Herin some proposed text for ISSUE-10:
Mapping Element and Type names 

This should also cover ISSUE-6:
mapping of enumerated values containing non-alphanumerics

XML and XML Schema Names

An XML Schema type, element or attribute may be any 
valid XML non-colonized name including names which may 
be reserved or not directly representable in a given 
programming language or other bound context. 
For example, "object", "static", "final", "class", 
"Customer-Profile" and "??", are all valid 
XML Schema symbol space values which may not be 
represented in many common programming languages. 

In addition a databinding tool may elect to represent 
XML content values as symbols in a bound context. 
For example, enumerated values may be represented in
some programming languages as enumerated types or

-Design Consideration-
A Schema author wishing to avoid any possible unnatural 
mapping between symbolic names in a given programming 
language, MAY restrict their Schema names to the intersection 
between the set of names valid in that particular 
programming language and the set of names valid in 
XML Schema. 

A databinding tool MUST provide a mechanism for 
mapping between the possible set of valid XML Schema 
symbols and other values used to be used as symbols,
and the set of symbolic names valid within the context of
the generated databinding.

An additional, possible suggestion, with options:
Note, there is no obvious set of
symbolic names used with an XML Schema and the set of all
popular programming languages and databinding environments
beyond limiting symbolic and other mapped names to 6/8/32 
uppercase/any US-ASCII/Latin letters/Letters and digits.

I can't say I'm fantastically happy with this, but
it does seem to be the best we can say on this subject.

Received on Tuesday, 2 May 2006 13:48:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:56 UTC