Re: [xml-dev] Should one adopt the tag naming convention of an existing

["Pete Cordell" <petexmldev@codalogic.com>]

Original Message From: "Cox, Bruce"
>
> Java developers have frequently complained of this, since the
> hyphen is apparently a reserved character in Java and their
> tools for automatically creating classes stumble over them
> when used in element names, requiring manual intervention,
> or other cleanup actions (so I’m told).
>
> Is the Java objection real?  Is there any real technical reason
> to prefer one over the other?

Our C++ data binding tool will convert hyphens in a name to underscores.
You can also specify whether you would like underscore/hyphen_separated
names converted to CamelCase, or vice versa.  This latter process is a bit
heuristic and may not always produce what people expect or want, but I see
no reason why other tools can't support it.  (There's also a completely
manual option.)  Naturally you have to make sure that there are no name
clashes after the conversion. Actually, if you put each class in its own
file you have to make sure that there are no name clashes when case is
ignored as the Windows system is not case sensitive.  It's all just part of
the job!

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
----- Original Message ----- 
From: "Cox, Bruce" <Bruce.Cox@USPTO.GOV>
To: "Uche Ogbuji" <uche@ogbuji.net>; <xml-dev@lists.xml.org>
Sent: Monday, February 06, 2012 3:57 PM
Subject: RE: [xml-dev] Should one adopt the tag naming convention of an
existing XML vocabulary or create one's own tag naming convention?


> WIPO Standard ST.36, vocabulary for patent documents, uses hyphen
> separators rather than underscore or camel case.  Java developers have
> frequently complained of this, since the hyphen is apparently a reserved
> character in Java and their tools for automatically creating classes
> stumble over them when used in element names, requiring manual
> intervention, or other cleanup actions (so I’m told).
>
> Is the Java objection real?  Is there any real technical reason to prefer
> one over the other?
>
> Personally, I find hyphenated element names easier to read than camel
> case, and vastly easier to type than underscores.
>
> In general, I’m in the same camp as many others with regard to the source
> of element names: the business vocabulary takes precedence.  We also try
> to follow ISO 11179-5, but where there is the slightest chance the results
> will confuse or snag the business users, we break those rules without
> hesitation.
>
> Bruce B Cox
> OCIO/AED/SAED
> 571-272-9004
>
> From: Uche Ogbuji [mailto:uche@ogbuji.net]
> Sent: 2012 February 3, Friday 15:18
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Should one adopt the tag naming convention of an
> existing XML vocabulary or create one's own tag naming convention?
>
> On Fri, Feb 3, 2012 at 1:11 PM, Andrew Welch
> <andrew.j.welch@gmail.com<mailto:andrew.j.welch@gmail.com>> wrote:
>> Here are two possibilities:
>>
>> 1. I will create a my own tag naming convention, independent of the XML
>> vocabularies that I will use.
>>
>> 2. I will adopt the tag naming convention of one of the XML vocabularies
>> that I will use. (Which one?)
>>
>> What do you recommend?
>
>
> There is only one way :) names should be all lower-case, with hyphen
> as a separator.  Camel case, or any thing else really, are awful for
> xml.
>
> I strongly agree, but of course this one is a very subjective matter. I
> curse Java for its propagation of the CamelCase eyesore.
>
> --
> Uche Ogbuji                       http://uche.ogbuji.net
> Weblog: http://copia.ogbuji.net
> Poetry ed @TNB: http://www.thenervousbreakdown.com/author/uogbuji/
> Founding Partner, Zepheira        http://zepheira.com
> Linked-in: http://www.linkedin.com/in/ucheogbuji
> Articles: http://uche.ogbuji.net/tech/publications/
> Friendfeed: http://friendfeed.com/uche
> Twitter: http://twitter.com/uogbuji
> http://www.google.com/profiles/uche.ogbuji
>