An unconventional XML naming convention

I am not a big fan of naming conventions but I don’t like to be obliged to follow naming conventions that do not seem to make sense!

One of the issues added by W3C XML Schema is that, in addition to define names for elements and attributes, you often have to also define names for simple and complex types.

Even though the W3C XML Schema recommendation says that elements, attributes, types, element groups and attribute groups have separate name spaces, many people want to have a mean to differentiate these spaces just looking at names and end up with using all kind of verbose suffixes.

The other issue is of course to define which character set and capitalization methods should be used.

It happens that the conventions most of my customers have to follow are the UN/CEFACT XML Naming and Design Rules Version 1.1 (PDF).

Following ebXML and UBL, they state that:

Following the ebXML Architecture Specification and commonly used best practice, Lower Camel Case (LCC) is used for naming attributes and Upper Camel Case (UCC) is used for naming elements and types. Lower Camel Case capitalizes the first character of each word except the first word and compounds the name. Upper Camel Case capitalizes the first character of each word and compounds the name.

I think that these rules do not make sense for a couple of reasons:

  1. There are many circumstances where elements and attributes are interchangeable and many vocabularies try to minimize the differences of treatments between elements and attributes. On the contrary, elements and attributes on one hand and types on the other hand are very different kind of beasts: elements and attributes are physical notions that are visible in instance documents while type are abstract notions that belong to schemas.
  2. This convention is not coherent with the UML naming conventions defined in the ebXML Technical Architecture Specification which says that Class, Interface, Association, Package, State, Use Case, Actor names SHALL use UCC convention (examples: ClassificationNode, Versionable, Active,InsertOrder, Buyer). Attribute, Operation, Role, Stereotype, Instance, Event, Action names SHALL use LCC convention (examples: name, notifySender, resident, orderArrived). XML elements and attributes are similar to UML object instances while types are similar to UML classes and they should follow similar naming conventions.

My preferred naming conventions for XML schemas (and those that I am going to follow in the future for projects that are not tied to other conventions) is to use LCC for element and attribute names and UCC for type and group names (or RELAX NG named patterns).

Sticking to this rule will give consistency with the Object Oriented world and allow me to get rid of suffixes to distinguish between what can be seen in the instance documents (elements and attributes) and what belongs to schemas (types, groups or RELAX NG named patterns).

Share and Enjoy:
  • Identi.ca
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Add to favorites

2 thoughts on “An unconventional XML naming convention”

  1. Hi Mark,

    You are making a very good point: the UBL XML naming conventions have been taken in the context of the UBL project to match well defined design principles.

    My comment has been made in the context of other vocabularies that do not share the same design principles and more or less blindly borrow your XML naming conventions out of their context.

    In that case, the distinction between elements and attributes is often quite subjective and that doesn’t seem to make much sense to use different naming rules for these two constructions.

    On the contrary, I think that it does make sense to differentiate concrete constructions that belong to the XML infoset (and that can be LCC by similarity to UML objects) from abstract constructions that only belong to the PSVI -when there is one- (and can be UCC by similarity to UML classes).

    Thanks for your feedback!

    Eric

  2. Hi Eric,

    Sorry you don’t agree with our conventions. You might want to look at line 225 of the ebTA spec which is the basis for both the UBL NDR and UN/CEFACT NDR documents. Further, from my perspective, the decision on LCC for attributes and UCC for elements and types makes perfect sense given how we are using those constructs in our models. Types and elements are representative of BIEs, and as such are different than attributes which are only supplementary components.

Leave a Reply

Your email address will not be published. Required fields are marked *

Enter your OpenID as your website to log and skip name and email validation and moderation!