XML元素是否有一个标准的命名约定？
XML文档是否有任何标准，事实上或其他方式？ 例如哪个是写“标签”的“最佳”方式？
<MyTag /> <myTag /> <mytag /> <my-tag /> <my_tag /> 同样，如果我有一个更好的属性的枚举值
<myTag attribute="value one"/> <myTag attribute="ValueOne"/> <myTag attribute="value-one"/>
我怀疑最常见的价值将骆驼 – 即
<myTag someAttribute="someValue"/>
特别是，如果与代码生成器混合（即将[序列化xml到对象]），空间会导致一些故障，因为没有多less种语言允许具有空格的枚举（要求两者之间的映射）。
XML命名规则
XML元素必须遵循这些命名规则：
- Element names are case-sensitive - Element names must start with a letter or underscore - Element names cannot start with the letters xml(or XML, or Xml, etc) - Element names can contain letters, digits, hyphens, underscores, and periods - Element names cannot contain spaces
任何名字都可以使用，不保留任何单词（xml除外）。
最佳命名实践
- Create descriptive names, like this: <person>, <firstname>, <lastname>. - Create short and simple names, like this: <book_title> not like this: <the_title_of_the_book>. - Avoid "-". If you name something "first-name", some software may think you want to subtract "name" from "first". - Avoid ".". If you name something "first.name", some software may think that "name" is a property of the object "first". - Avoid ":". Colons are reserved for namespaces (more later). - Non-English letters like éòá are perfectly legal in XML, but watch out for problems if your software doesn't support them.
命名样式
没有为XML元素定义的命名样式。 但是这里有一些常用的：
- Lower case <firstname> All letters lower case - Upper case <FIRSTNAME> All letters upper case - Underscore <first_name> Underscore separates words - Pascal case <FirstName> Uppercase first letter in each word - Camel case <firstName> Uppercase first letter in each word except the first
对我来说，就像讨论一种编程语言的代码风格一样：有些人会争论一种风格，另外一些人会辩护另一种风格。 我看到的唯一共识是：“select一种风格，保持一致”！
我只注意到很多XML方言只使用小写名称（SVG，Ant，XHTML …）。
我没有得到“属性值中没有空格”的规则。 不知怎的，它发送到“什么要放在属性和怎样把文本放在”辩论。
也许这些不是最好的例子，但是有一些在属性中使用空格的着名的XML格式：
- XHTML，特别是类属性（你可以放两个或更多的类），当然还有alt和title属性。
- SVG，例如path标记的d属性。
- 两个与风格属性…
我不完全理解反对这种做法的论点（似乎只适用于某些用途），但至less是合法的，而且被广泛使用。 显然有缺点。
哦，你不需要自动closures斜线之前的空格。 🙂
我赞成TitleCase的元素名称，和camelCase的属性。 没有任何空间。
<AnElement anAttribute="Some Value"/>
另外，我做了一个快速search最佳实践的XML，并提出了这个相当有趣的链接： XML模式：最佳实践 。
我倾向于倾向于使用小写字母或驼峰标签，因为属性通常应该反映数据值 – 而不是内容 – 我会坚持一个可以用作任何平台/语言可能感兴趣的variables名称的值，即避免空格两种forms可以
这是主观的，但是如果元素标签中有两个单词，那么通过在单词之间添加下划线（例如<my_tag> ）而不是使用分隔符可以增强<my_tag> 。 参考： http : //www.w3schools.com/xml/xml_elements.asp 。 所以根据w3schools的答案是：
<my_tag attribute="some value">
该值不需要使用下划线或分隔符，因为您可以在属性值中使用空格，但在元素标签名称中不能使用空格。
许多以文档为中心的XML方言使用小写的基本拉丁文和短划线。 我倾向于这样做。
将XML直接映射到编程语言标识符的代码生成器是脆弱的，并且在便携式文档格式中应避免（除了天真的对象序列化，如XAML）; 为了最好的重用和信息的长寿，XML应该尝试匹配域，而不是实现。
rss可能是世界上消费最多的XML模式之一，它是骆驼。
规格在这里： http : //cyber.law.harvard.edu/rss/rss.html
当然，模式中没有节点属性，但所有的节点元素名称都是camelCased。 例如：
lastBuildDate managingEditor pubDate
我通常将XML命名约定与其他代码中的相同命名约定alignment。 原因是当我将XML加载到Object中时，其属性和元素名称可以被称为与项目中当前使用的相同的命名约定。
例如，如果您的JavaScript使用camelCase，那么您的XML也使用camelCase。
微软拥抱两个约定：
-
对于configuration ，Microsoft使用camelCase 。 看看Visual Studio的configuration文件。 对于VS2013，它存储在：
C：\ Program Files（x86）\ Microsoft Visual Studio 12.0 \ Common7 \ IDE \ devenv.exe.config
例：
<startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" /> </startup>
- 微软也使用UpperCase作为他们的XAML。 我想这是区别于HTML（使用小写）。
例：
<MenuItem Header="Open..." Command="ApplicationCommands.Open"> <MenuItem.Icon> <Image Source="/Images/folder-horizontal-open.png" /> </MenuItem.Icon> </MenuItem>
没有明确的build议。 根据W3C的其他build议， XHTML的build议 ，我select了小写：
4.2。 元素和属性名称必须小写
对于所有HTML元素和属性名称，XHTML文档必须使用小写字母。 这种区别是必要的，因为XML是区分大小写的，例如<li>和<LI>是不同的标签。
XML命名规则
XML元素必须遵循这些命名规则：
- 名称可以包含字母，数字和其他字符
- 名称不能以数字或标点符号开头
- 名称不能以字母xml（或XML或Xml等）开头，
- 名称不能包含空格可以使用任何名称，不保留任何单词。
来源： W3学校
我一直在寻找一个很好的方法，也读这个线程和其他人，我会投票使用连字符 。
它们广泛用于ARIA（ https://developer.mozilla.org/de/docs/Web/Barrierefreiheit/ARIA ），这在很多源代码中都可以看到，因此很常见。 正如在这里已经指出的那样，它们当然是允许的，这也在这里解释： 使用 – 在XML元素名称中
另外还有一个好处：在与CSS结合编写HTML时，默认情况下，您经常会使用名称中使用连字符作为分隔符的类。 现在，如果您使用CSS类的自定义标签或使用CSS类的标签的自定义属性，那么类似于：
<custom-tag class="some-css-class">
是更一致的，并且读 – 在我的愚见中 – 比以下更好：
<customTag class="some-css-class">
检查这个链接…. XML标准和约定
编辑：此链接已损坏，新链接如下： http : //docs.oracle.com/cd/E82085_01/141/funtional_artifacts_guide/or-fasg-standards.htm
