Tag naming syntax

[Vincent Buller <vincent@and.nl>]

Hi Ram,

I just browsed through the OTA docs, and they too use the TagName
convention, using capitals at the start of every word. THey also refer to
some element names from ebXML architecture, and that uses similar syntax.
The exact OTA guidelines are (distinguised are mandatory and advised rules):

====== START OTA QUOTE ========

3.3.2. Guidelines for tag naming conventions

A key part of the XML grammar is consistent naming conventions for tags that
represent the
infrastructure and business-related elements. Tag name writers MUST follow
these rules unless
business requirements require other naming conventions.
· Use mixed case tag names, with the leading character of each word in upper
case and the
remainder in lower case.
Example: <PaymentForm>
· Acronyms are discouraged, but where needed, use all upper case.
Example: <PropertyURL>
· Where acronyms or single-letter words cause two upper case characters to
be adjacent,
separate them with an underscore ( _ ) .
Example: <PO_Box>
· Illegal characters cannot be used (e.g.: forward slash, etc.). Recommended
characters in a tag
name are basically limited to letters and underscores.
Example: (not allowed) <Date/Time>
· The use of periods, which appeared in OTA version 1 to indicate the
version and hierarchy, is
discouraged.

Tag writers SHOULD use these guidelines when constructing tag names.
· Use the same tag names with elements in a similar child structure
Example: <ContactAddress>
<HomeAddress>
<WorkAddress>
· Use plural tag names only for collections.
Example: <CreditCards>
<CreditCard>
· Element and attribute names should not exceed 25 characters. Tag names
should be spelled
out except where they exceed 25 characters, then standardized abbreviations
should be
applied, using the abbreviations in OTA Version 1 as a baseline.
Example: <ShareSyncInd>
· Element and attribute names should incorporate the proposed list of
suffixes for tag names as
recommended by ebXML. The ebXML Data Element Representation Classes are the
following (includes ebXML definition):
Amount - A number of monetary units specified in a currency where the unit
of currency is
explicit or it may be implied.
Code  - A character string that represents a member of a set of values.
Boolean  - An enumerated list of two, and only two, values which indicates a
condition
such as on/off; true/false etc. (It was the general consensus to use ‘Flag’
as a
term to indicate a Boolean value.)
Date - A day within a particular calendar year. Note: Reference ISO 8601.
Time - The time within any day in public use locally, independent of a
particular day.
Reference ISO 8601:1988.
DateTime - A particular point in the progression of time. Note: This may
incorporate
dependent on the level of precision, the concept of date,
Identifier - (standard abbreviation Id, meaning a unique identifier) A
character string used to
identify and distinguish uniquely, one instance of an object within an
identification scheme.
Name - A word or phrase that constitutes the distinctive designation of a
person, object,
place, event, concept etc.
Quantity - A number of non-monetary units. It is normally associated with a
unit of
measure.
Number - A numeric value which is often used to imply a sequence or a member
of a
series.
Rate - A ratio of two measures.
Text - A character string generally in the form of words.
Measure - A numeric value that is always associated with a unit of measure.
· OTA suggests the additional tag naming convention of ‘Type’ to be used for
an enumeration.
Type An enumerated list of values from which only one value can be chosen at
a time.


====== END OTA QUOTE ========

I believe we can take the mandatory rules, although I would personally not
make an exception for PO_Box and just write POBox to put consistency over
"readability".

From the other rules, I would like to scrap the 25 character limit. IMO it's
more consistent to forego on all abbreviations except acronyms. So not allow
PstBx, but do use POBox.

About the typenames as suffix: I think its useful if used carefully, and it
should not be enforced. A "Street" is a "Street", and not a "StreetString"
or a "StreetName".

Any comments?

Cheers,
Vince