XML Schema Component Naming Convention

Question

Is there a naming convention when you create an XML Schema? For example,
When you create a Type component, then the first letter of its name should be upper case ie. BMW, Honda, AutombileEngine ...etc.
When you create an Element component, then the first letter of its name is lowercase ie. engine, car, guestCar ..etc.
Do we have such naming convention for XML Schema?
Thanks

Answer 1

I am giving this from my document which i prepared for one of my customer
2     General Guidelines for design of XML schema documents
The representation of data in an XML format will be a key component of development within SOA. Therefore, the design and development of XML schemas should be as rigorous an activity as designing and developing code or designing database schemas. As such, when creating an XML schema you should be working within a development process and working to a set of design guidelines and coding standards (when writing the XML schema file). XML schemas should be reviewed for accuracy and compliance with guidelines and standards. Each of the requirements in the list below is a general requirement for all XML schemas to be deployed in the SOA environment.
•     Understandable: XML schemas should be clear, consistent and unambiguous. They should contain human readable documentation and, where appropriate, links to requirements or design documents.
•     Semantically Complete: An XML schema should define, for one or more target XML documents, each and every element and attribute that is understood by your solution when processing target documents.
•     Constraining: XML schemas are used as contracts between both publisher and consumer. As such, they must be able to be validated as concisely as possible. When designing an XML schema constraints should be identified for the values for all the elements and attributes that the application uses and relies on to the set of values that the application can handle. A valid document should imply valid data within the limits of what can be specified by the XML Schema language.
•     Uniquely identifiable: XML schemas should import and include other XML schema files rather than duplicating types and elements locally.
•     Reusable: XML schemas should be specified in such a way that types and other XML schemas can leverage elements. Every type defined in an XML schema that is the content type of an attribute or an element should be defined globally (i.e., at the top level in the Schema). Types that are defined globally can be reused in other XML schemas. Schemas should be separated into logical sections which can be included into the main schema file.
•     Extensible: Schemas should be designed to be extensible—that is, new elements and attributes can be inserted throughout the document.
Every schema should use at least two namespaces – the targetNamespace and the XML Schema (http://www.w3.org/2001/XMLSchema) namespace.
Create typed elements that can be referred to by object elements:
Example:
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.soa.com"
xmlns="http://www.soai.com"
elementFormDefault="qualified">
<xsd:complexType name="PersonType">
<xsd:sequence>
<xsd:element name="Name" type="xsd:string"/>
<xsd:element name="SSN" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.company.org"
xmlns="http://www.company.org"
elementFormDefault="qualified">
<xsd:include schemaLocation="Person.xsd"/>
<xsd:include schemaLocation="Product.xsd"/>
<xsd:element name="Company">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Person" type="PersonType" maxOccurs="unbounded"/>
<xsd:element name="Product" type="ProductType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
•     Recognize that with XML Schemas you will not be able to express all your business rules.
o     Express those business rules using XSLT.
•     Use type definitions
Elements vs Attributes
•     Use attributes for metadata about the parent element.
•     Use attributes for data that is semantically tied to the enclosing element.
•     Use elements for data that have a meaning separate from the enclosing element.
•     Use attributes when the value will be frequently present in order to improve the human readable form of an XML instance document or reduce its size.
•     If you don't know which to use, then use the element form (which is more extensible).
2.1.1     Element, Types and attribute names
Create a descriptive name without it being excessively long (no more than 32 characters).
Elements and Types should be named in Upper Camel Case. Upper Camel Case capitalizes the first character of each word and compounds the name (remove all whitespace).
Attributes should be named in Lower Camel Case. Lower Camel Case capitalizes the first character of each word except the first word and compounds the name.
Simple and Complex type names
XML Schema has separate symbol space for elements and types so they may have the same name. The best practice is to append the word "Type" to all simple and complex type names to aid in human readability and comprehension.
Element, attribute and type names MUST be in a singular form unless the concept itself is plural.
2.1.1.1     XML Schema versioning
Use major and minor version tracking:
Major—completely different structure and semantics, most likely not backward compatible
Minor—backward compatible changes which introduce new features without removing or changing the semantics of existing structures
2.1.1.2     Indication of version in the namespace URI
Specify a namespace URI as follows
http://$domain/$groupSpecifier/$namespaceTitle/$version
The groupSpecifier can include several levels, e.g., /www.soa.com/SOA/USA/.
An example namespace could be:
http://www.soa.com/SOA/order/2