- From: <jon.calladine@bt.com>
- Date: Tue, 19 Sep 2006 15:04:33 +0100
- To: <paul.downey@bt.com>, <public-xsd-databinding@w3.org>
I think we have come to the conclusion that the most stringent restriction is suitable for the Basic Patterns doc and that any other valid ncname will be an advanced pattern. As per Peter and Pauls exchange the following is the bare pattern: *** //xs:schema//@name values which conform to the following pattern are "Basic": identifier ::= (letter|"_") (letter | digit | "_"){0,30} letter ::= ("a".."z") | ("A".."Z") digit ::= "0".."9" Any other @name is marked as "Advanced". *** I have slightly modified my orginal text below which we can now relegate to whatever supporting documentation we choose to produce (or not). Mappings Rationale. 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 that for ultimate interoperability element and type names should only be constructed using aplphanumeric US ASCII and the "_" (underscore. Where any characters other than these are used in a schema document the basic patterns validation rules will generate a message to warn the schema author of the potential problem:
Received on Tuesday, 19 September 2006 14:05:00 UTC