元素名称的案例约定?

Ian*_*oyd 117 xml case-sensitive

XML中有关于元素大小写的正式建议吗?

我知道XHTML使用小写元素名称(而不是HTML,它通常使用大写但不区分大小写.)

但我在谈论XML的通用内容.

小写:

<customer> 
   <accountnumber>619</accountnumber>
   <name>Shelby Lake</name>
</customer>
Run Code Online (Sandbox Code Playgroud)

骆驼香烟盒:

<customer> 
   <accountNumber>619</accountNumber>
   <name>Shelby Lake</name>
</customer>
Run Code Online (Sandbox Code Playgroud)

PascalCase:

<Customer> 
   <AccountNumber>619</AccountNumber>
   <Name>Shelby Lake</Name>
</Customer>
Run Code Online (Sandbox Code Playgroud)

大写:

<CUSTOMER> 
   <ACCOUNTNUMBER>619</ACCOUNTNUMBER>
   <NAME>Shelby Lake</NAME>
</CUSTOMER>
Run Code Online (Sandbox Code Playgroud)

注意:我正在寻找被引用的指导而不是意见.但是,最多投票的意见可以被视为一个指导方针.

Pet*_*ham 87

源自W3C的大多数XML标准倾向于使用带有连字符的小写.

有看到XML作为平台中立的文件,其中W3C标准尽量鼓励和语言如XAML其中看到XML作为一个平台特定的对象图的序列化格式之间的哲学区别.

如果你不使用XML作为一个平台中立的文档格式,但作为一个专用的序列化,那么你还不如保存自己的一些麻烦,并有一个1:XML名称和平台特定名称之间的一一对应.但是为了这个目的,几乎任何其他对象图格式都比XML更好.

如果你是,那么你可能想要适应XHTML,XSLT,SVG,XProc,RelaxNG和其他.

  • @WarFox我认为没有人提出正式建议.IME,来自w3c的互操作性格式往往采用连字符形式; 来自Microsoft和其他一些格式的格式往往与实现和用于实现的语言中的对象名称的约定紧密耦合.如果您使用XML来解耦系统,那么不将XML与该系统的一个组件的语言风格耦合可能会迫使您根据消息而不是对象进行思考,因此我建议使用小写和连字符样式. (9认同)
  • 这是否意味着建议或不建议使用连字符小写? (7认同)
  • 请注意,"带连字符的小写"在XSLT中存在一些问题.具体而言,很容易将一个称为"年龄与年龄"的节点混淆为公式"年龄 - 年龄"(例如,从年份中减去年龄) (5认同)
  • @RichardKennard这种混乱只可能在人类层面吗?对于xslt,运算符周围所需的空格(?)提供了清晰明确的区分,对吗? (3认同)
  • @KarlKieninger 确实如此,但恕我直言,人类层面的混乱是一个重大问题。请参阅下面我的扩展答案。 (2认同)

Met*_*urf 62

这并不重要,但我总是偏向于PascalCase for Elements和camelCase的属性:

<Root>
  <ParentElement attributeId="1">
    <ChildElement attributeName="foo" />
  </ParentElement>
</Root>
Run Code Online (Sandbox Code Playgroud)


lav*_*nio 30

没有正式的建议.

由于XML的设计具有保存文档在不同系统之间交换信息的双重目的,因此设计它是为了能够匹配使用它的应用程序.

因此.Net XML倾向于使用ProperCasing(见证XAML),而其他XML将使用camelCasing,python_conventions,dot.naming甚至COBOL-CONVENTIONS.W3C似乎喜欢小写与短划线(相当于一点点)(例如XSLT)或仅仅是低速行动(例如MathML).

我喜欢所有的小写,没有下划线,因为这意味着更少使用[Shift]键,我的手指有点懒.:)

  • 似乎如果它的目的是"交换信息",那么绝对需要一个命名约定的标准.这也适用于多个特定实现所使用的任何文档(例如,不是一次性序列化). (2认同)

Koe*_*eef 23

添加到Metro Smurf的答案.

国家信息交换模型(NIEM:http://en.wikipedia.org/wiki/National_Information_Exchange_Model)说要使用:

  • 上层CamelCase(PascalCase)用于元素.
  • (下)camelCase属性.

当您希望符合某些标准时,NIEM是一个很好的选择.


olu*_*ies 13

有关 若干标准中使用的一些示例规则,请参阅UN/CEFACT XML命名和设计规则技术规范版本3.0第23页.

细节(2009年12月17日版本3.0第23页):

  • LowerCamelCase(LCC)必须用于命名属性.
  • UpperCamelCase(UCC)必须用于命名元素和类型.
  • 除非概念本身是复数,否则元素,属性和类型名称必须是单数形式.

(其他链接,瑞典网站)

  • 尽管确实很有趣,但是在此特定部分/页面上引用的文档建立了XML ** Schemas **的规则,而不是遵循该模式的解析器/ xml文档。这是两件事。 (3认同)
  • -1:你的链接坏了 - 也许它是一个内部URL?请修复它,我将删除downvote. (2认同)

Ric*_*ard 12

为了扩展我上面评论:在XSLT中使用带有连字符的小写字母有一些问题.具体而言,很容易将称为"年龄与年龄"的节点混淆为公式"年龄 - 年龄"(例如,从年份中减去年龄).

正如@KarlKieninger指出的那样,这只是人类层面的问题而不是XSLT解析器.然而,由于这通常不会产生错误,因此使用'带小写连字符'作为标准是要求麻烦,恕我直言.

一些相关的例子:

<a>1</a><b>1</b>
<xsl:value-of select="a+b"/>
outputs 2, as expected

<a>1</a><b>1</b>
<xsl:value-of select="a-b"/>
DOES NOT ERROR, BUT OUTPUTS NOTHING AT ALL
Run Code Online (Sandbox Code Playgroud)

在上面的代码中,必须在减法运算符之前放置至少一个空格,但是对于加法运算符没有这样的要求.

<a-b>1</a-b><c>1</c>
<xsl:value-of select="a-b -c"/>
outputs 0, as expected
Run Code Online (Sandbox Code Playgroud)

但请注意以上是多么令人困惑的阅读!

<a>1</a><a-b>3</a-b><b>2</b>
<xsl:value-of select="a-b"/>
outputs 3

<a>1</a><a-b>3</a-b><b>2</b>
<xsl:value-of select="a -b"/>
outputs -1
Run Code Online (Sandbox Code Playgroud)

单个空格的存在会改变上面的输出,但这两个变量都不是错误.

  • 出售.此外,MS .NET代码生成工具(xsd.exe)将在创建反序列化类时简单地删除连字符.因此,如果像"alpha-beta"这样的属性,你会得到"alphabeta".因此,不仅名称不能完全翻译,而且更难以阅读.如果你需要使用MS SQL构建xml连字符也是一个痛苦.MS特定的东西不应该规定一个标准,但它的使用范围很广,我认为它可以算作一个考虑因素.它引导我走向下划线的小写或混合案例. (2认同)

ken*_*ero 10

Google的样式指南推荐(甚至可能是强制性的)camelCase用于所有元素名称以及属性名称.