RE: ISSUE-10: Mapping Element and Type names

Hi Pete

> I agree with the requirement that tools should support all mappings.  
> I'm just slightly worried that there's an issue of what can be done 
> vs. what can easily be done.  For example, a tool could map Chinese 
> characters to their Unicode number (e.g. Type_U1234_U6543), but a 
> Chinese developer might decide that they prefer to use ASCII XML names 
> in preference to this.

a nice use-case! 

Of course the mapping doesn't have to be mechanical, but mechanised
translation such as this could offer sensible defaults. 

> Admittedly, most tools allow manual mapping of names, 
> but again, this involves more work, so it's another trade-off 
> that a developer may choose to make.

In such circumstances I'd imagine a binding tool using a developer 
provided a map file, or other meta-data to provide a more convenient 
translation. 

I'd see how such mappings should be defined is likely implementation 
specific, and falling into the category "annotations", which are out 
of scope for the basic patterns document, but something we could offer 
as an advanced pattern.

> So is the purpose of the document to advise purely on what is possible 
> (even if it is unattractive), or should it give guidance on language 
> specific trade-offs?  For example, it could advise that not all XML names 
> are directly representatable in some programming languages (such as C/C++, SQL etc), 
> and as a result the automatically mapped names may be non-intuitive, 
> or additional manual configuartion may be required if names are not chosen 
> with with these limitations in mind.

I personally think it has to be the latter.
Advice for specific programming languages is a slippery slope, 
given there is always another language.  It's also out of scope.

Paul

Received on Monday, 16 January 2006 14:17:40 UTC