Re: [xml-dev] Should one adopt the tag naming convention of anexisting 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?
Having written a data binding tool [1] from XML to a language with similar identifier rules as Java's, I can say that sure there is a technical obstacle. However, this technical obstacle is the least one would expect when trying to automate correspondences between one technical context and another, very different technical context. People who use this as an excuse for insisting on CamelCase in XML are either omitting or just fudging the fact that it's the least of the issues they have to deal with. According to such objections, they couldn't use XML namespaces at all (the colon has the same problem as the hyphen), nor even the original, pre-namespace idea of the likes of xml:space and xml:lang.
Such objections also, as I've argued in this thread, get the balance of utility wrong. It is the job of the developer to deal with such things without imposing restrictions for his own convenience on the user space. If some of us (you and I, and a lot of other users I've encountered) prefer the hyphens to the CamelCase, then the debate should have nothing to do with programming at all. It should only be about usability for end users. If we programmers can't process the more usable options, that's our own fault in this particular case, because a mechanical conversion from one naming convention to the other is always possible.
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.
Sensible.
