SV: Element names guidelines

>This <Car><CarDescription> approach is an unnecessary repetition of the
>"Car" concept and appears to be what Jeni Tennison warned against
>earlier in this thread. IMO this is usually caused by not properly
>modeling your data before authoring the schema.
Probably, however it seems to me as I just noted in another email that this
kind of construction shows up really an awful lot in languages defined using
XML Schema. 

>You might want to look at the UBL Naming and Design rules as a good
>source of a comprehensive standards-based approach. 
Yeah I'm familiar with it. 

I have to spend all day long with the Danish UBL Invoice
requirements/schemas etc.  




> -----Original Message-----
> From: xmlschema-dev-request@w3.org
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Bryan Rasmussen
> Sent: Tuesday, November 23, 2004 3:29 AM
> To: 'Frans Englich'
> Cc: xmlschema-dev@w3.org
> Subject: SV: Element names guidelines
>
>
>
>
>
> You have an element that you want to match the concept car
> description how would you naturally embody that concept in xml?
>
> wouldn't it be
> <car>
> <description></description>
> </car>
> (obviously there are numerous designs patterns that one might
> use but I will stick with this one for the point of this post)
>
> Instead what seems to happen with structures where xml schema
> is used is that you get naming conventions like this
>
> <Car>
> <CarDescription></CarDescription>
> </Car>
>
> In fact this is the naming convention where I work.
>
> this naming convention seems to be related to naming
> conventions often used in certain object oriented languages
> and of course in that we want to be able to say that a
> description of a car has various limitations on it that a
> generic description might not. (Which in the case of my work
> is also related to naming and design rules that do not allow
> local declaration of elements but require all elements to be
> globally declared)
>
> I believe that this an example of the drawbacks of xml schema
> as an xml validation language, not to mention its drawbacks
> as a language in the areas of data typing, and data binding
> descriptions.
>
>
>
>               
>
> -----Oprindelig meddelelse-----
> Fra: Frans Englich [mailto:frans.englich@telia.com]
> Sendt: 18. november 2004 15:25
> Til: xmlschema-dev@w3.org
> Emne: Element names guidelines
>
>
>
>
> Hello,
>
> At the risk of starting a flamefest, I wonder: What is the
> best naming conventions for elements and attributes? A
> crucial question in modeling XML formats.
>
> Assuming the phrase "car description" should be translated to
> an element name, and the criteria for judgment are easy to
> type and readability, there exist a number of different alternatives:
>
>
> <CarDescription>
> ----------------
> In my opinion, too elaborated; The capitalized C is
> unnecessary since the phrase is automatically distinguished
> at the boundaries by the tag characters.
>
> <carDescription>
> ----------------
> I'll call this the WXS-style. I find it (visually) beautiful
> and simple.
> It's
> relatively easy to read. Perhaps I'm biased by the Qt/KDE
> API. Regarding typing ergonomics it perhaps could be better
> than capitalized letters.
>
>
> <car-description>
> -----------------
> I'll call this the XSLT-style. IMO, more heavy and dense in
> its look, but easier to type.
>
> <cardescription>
> ----------------
> The Docbook-style. Hard to read but fast to type. That this
> naming scheme was chosen, suggests that other criteria than
> readability and typing ergonomics exists..
>
>
> But which one is best, and is there other alternatives? What
> other criteria are there, rendering my ramblings simplified?
> Does it depend on usage scenario?
>
> What was the reasonings behind XSLT's and WXS's styles?
>
>
> Cheers,
>
>               Frans
>
>
>
>
>

Received on Tuesday, 23 November 2004 13:42:16 UTC