요소 이름에 대한 사례 규칙?

요소 이름에 대한 사례 규칙?

---

XML의 요소 케이싱에 대한 공식적인 권장 사항이 있습니까?

XHTML은 소문자 요소 이름을 사용한다는 것을 알고 있습니다 (대문자를 대문자로 사용하지만 대소 문자를 구분하지 않는 HTML과 반대).

그러나 일반적인 내용의 XML에 대해 이야기하고 있습니다.

소문자 :

<customer> 
   <accountnumber>619</accountnumber>
   <name>Shelby Lake</name>
</customer>

낙타 케이스 :

<customer> 
   <accountNumber>619</accountNumber>
   <name>Shelby Lake</name>
</customer>

파스칼 케이스 :

<Customer> 
   <AccountNumber>619</AccountNumber>
   <Name>Shelby Lake</Name>
</Customer>

대문자 :

<CUSTOMER> 
   <ACCOUNTNUMBER>619</ACCOUNTNUMBER>
   <NAME>Shelby Lake</NAME>
</CUSTOMER>

참고 : 의견보다는 인용 지침을 찾고 있습니다. 그러나 투표율이 가장 높은 의견은 지침으로 간주 될 수 있습니다.

---

W3C에서 시작된 대부분의 XML 표준은 하이픈으로 소문자를 사용하는 경향이 있습니다.

W3C 표준이 권장하는 플랫폼 중립적 문서의 형식으로 XML을 보는 것과 XML을 플랫폼 별 객체 그래프의 직렬화로 보는 XAML과 같은 언어는 철학적으로 구별됩니다.

XML을 플랫폼 중립적 문서 형식으로 사용하지 않고 응용 프로그램 특정 직렬화로 사용하는 경우 귀찮게하고 XML 이름과 플랫폼 특정 이름 사이에 1 : 1 대응 관계를 가질 수 있습니다. 그러나 거의 모든 다른 객체 그래프 형식이 XML보다 좋습니다.

그렇다면 XHTML, XSLT, SVG, XProc, RelaxNG 및 나머지와 함께 사용할 수 있습니다.

---

중요하지는 않지만, 나는 PascalCase for Elements와 camelCase에서 항상 부분적이었습니다.

<Root>
  <ParentElement attributeId="1">
    <ChildElement attributeName="foo" />
  </ParentElement>
</Root>

---

공식적인 추천은 없습니다.

XML은 문서 를 보유 하고 서로 다른 시스템간에 정보를 교환 하는 두 가지 목적 으로 설계되었으므로 이를 사용하여 응용 프로그램 을 일치 시킬 수 있도록 설계되었습니다 .

따라서 .Net XML은 ProperCasing (증인 XAML)을 사용하는 반면 다른 XML은 camelCasing, python_conventions, dot.naming 및 COBOL-CONVENTIONS를 사용합니다. W3C는 대소 문자를 가진 quite-a-bit (예 : XSLT) 또는 대소 문자를 구분하는 단어 (예 : MathML)를 좋아하는 것 같습니다.

[Shift] 키를 적게 사용한다는 것을 의미하기 때문에 소문자를 모두 사용하고 밑줄을 사용하지 않으며 손가락이 약간 게으 릅니다. :)

---

Metro Smurf의 답변에 추가하십시오.

국가 정보 교환 모델 (NIEM : http://en.wikipedia.org/wiki/National_Information_Exchange_Model )은 다음을 사용한다고 말합니다.

• 요소에 대한 상단 CamelCase (PascalCase).
• (아래) camelCase는 속성입니다.

NIEM은 일부 표준을 준수하려고 할 때 좋은 옵션을 제공합니다.

---

여러 표준에서 사용되는 몇 가지 규칙에 대해서는 UN / CEFACT XML 이름 지정 및 디자인 규칙 기술 사양 버전 3.0 페이지 23을 참조하십시오.

세부 사항 (2009 년 12 월 17 일 버전 3.0의 23 페이지부터) :

• LCC (LowerCamelCase)는 이름 지정 속성에 사용해야합니다.
• UpperCamelCase (UCC)는 요소 및 유형의 이름을 지정하는 데 사용해야합니다.
• 개념 자체가 복수가 아닌 경우 요소, 속성 및 유형 이름은 단수 형태이어야합니다.

( 다른 링크, 스웨덴어 사이트 )

---

위의 설명 을 확장하려면 '하이픈이있는 소문자'를 사용하면 XSLT에 몇 가지 문제가 있습니다. 특히 '연령부터'라는 노드를 '연령-연령'공식과 혼동하기 쉽습니다 (예 : 연도에서 연령을 빼기).

As @KarlKieninger points out, this is only a problem at the human level and not for the XSLT parser. However since this will often not produce an error, using 'lowercase with hyphens' as a standard is asking for trouble, IMHO.

Some pertinent examples:

<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

In the above code, you must put at least one space before a subtraction operator, but there is no such requirement for an addition operator.

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

But note how confusing the above is to read!

<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

The presence of a single space changes the output above, but neither variant is an error.

---

Google's style guide recommends (perhaps even mandates) camelCase for all element names, as well as attribute names.

---

The original intent for XML casing was lower case with hyphens. It's case sensitive and doesn't require you follow that convention -- so you can do whatever you want. I have no citations, sorry.

---

I wouldn't say HTML "canonically" uses uppercase. I think originally uppercase was used to visually separate HTML from the content more easily. With syntax highlighting nowadays, that's just not necessary.

I veer towards lowercase, with dashes if necessary (quicker to type, too). Mixing case in XML just feels wrong to me.

---

Camel case gets my vote.

As to cited examples perhaps this question can be come the link people cite.

참고URL : https://stackoverflow.com/questions/1074447/case-conventions-on-element-names