Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


SV: [xml-dev] a useful naming convention

From: James Lindley Walford <jlw@----.-->
To: 'Michael Kay' <mike@--------.--->,'Bryan Rasmussen' <bry@------.--->, jim.fuller@--------.--.--
Date: 8/2/2005 12:45:00 PM
>As far as the internal syntax of a name is concerned, the only important
>thing is to try and be consistent: use hyphens or underscores or camelCase,
>but not all three interchangeably.

>Michael Kay

I was taught to avoid hypens and underscores due to potential problems with
e.g. data-binding, though I can't provide concrete examples of such a
problem. A myth or a reality?

>- reduce keystrokes....I avoid camelhumps or capitals and tend to use
>indenting as primary mechanism for making things easier to read

>Jim Fuller

Some of the element names I see are so long as to make them virtually
unreadable without some method of distinguising e.g. an object term from a
property in a name. Indenting has many merits, but relies on structural
context to identify an element if it is used to e.g. remove part of an
element name. In deeply nested structures it can also require a fair amount
of horizontal scrolling....

>The main debate about naming is the scope of uniqueness of a name. Should
>the title of a chapter have the same element name as the title of a
section?

>Michael Kay

Good question. Title is a property of both document, chapter and section.
It's also likely to have the same basic type (e.g. a string). It's also a
property of a person's name (Mr, Ms, Sir), an entirely different thing. To
what extent should context alone elucidate the meaning of the element name?
Well it could be argued that a Title is a Title, whether it applies to a
document or a section, and therefore should be non-unique within the scope
of the entire document, but unique to each parent tag. But then you might
need to rename Title under person name to maintain the difference.

The schemas I work with are designed after the principle of explicit
delineation, such that the element names end up as e.g.

DocumentTitle
ChapterTitle
SectionTitle and
PersonTitle 

Needless to say, this can end up creating some very long names (see above).
It also becomes more difficult to work with generic handling of any Title
element, as there are now three types of title used in respect to a document
and its subsections.

Length of element name is also one reason why some acronyms might be thought
useful, especially with regard to e.g. organisation names. Apart from that,
many acronyms are in such daily usage that they convej more meaning than the
fully expanded version? I know what an ISBN number is, but I'm not
altogether sure I know exactly what the S in that stands for....

>if wanting to delineate type, then use some sort of explicit schema
>attribute to do this job

Well XML Schemas are themselves XML documents, with the same (if not more
complex) issues of readability. In fact it's XML Schemas I tend to be
reading and wishing for a convention that would simplify things a little -
especially (as Bryan mentioned) where an element may be referenced via an
imported or included schema.


James Walford


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent