MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] Use of camel case (Naming and Design Rules specifications)
Paul Grosso wrote:
> Thanks for the analysis, Robin.
>
> I have nothing against camelCase in general
> (though I've never seen an hRef attribute!).
I do, for the simple reason that technologies like XSLT and CSS will
silently fail when you specify a select or match expression that is
wrong only in the case of the attribute or element type name. In XSLT
you have to go to extra effort to trap mispellings of this sort
(somewhat easier to do in XSLT 2.0). But I don't know of any way to do
it in CSS.
This, I think, makes XML fundamentally different from programming
languages, where failure in the case of incorrect case is early and clear.
And, to respond to Robin's assertion that changing NAMECASE GENERAL to
"NO" was common practice--it was not in my experience, at least not
before the advent of XML.
In particular, as an application designer, I would never want to
encourage the design of markup where constructs with different semantics
differed only in case.
> My concern is mixing runtogethernames,
> hyphen-separated-names, and camelCaseNames
> all in the same vocabulary tends to make for
> a lot of confusion. One can spend hours
> trying to figure out what's wrong with some
> markup or script only to realize finally
> that one occurrence of topicRef was
> misspelled as topicref or one list-item
> was misspelled listItem.
I agree wholeheartedly with Paul here.
Either all the names in DITA should be reworked to use camelcase or we
should continue to use the naming pattern already established.
Cheers,
Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8155
ekimber@innodata-isogen.com
www.innodata-isogen.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]