요소 이름에 대한 대소문자 규칙?

요소 이름에 대한 대소문자 규칙?

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 표준은 하이픈과 소문자를 사용하는 경향이 있습니다.

XML을 W3C 표준에서 권장하는 플랫폼 중립 문서의 형식으로 보는 것과 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은 적절한 Casing(증인 XAML)을 사용하는 경향이 있는 반면, 다른 XML은 camelCasing, python_conventions, dot.naming, 심지어 COBOL-CONVENTENS를 사용합니다.W3C는 대시가 포함된 소문자-a-비트(예: XSLT)를 좋아하거나 소문자 단어를 함께 스매싱하는 것(예: MathML)을 좋아하는 것 같습니다.

저는 소문자는 다 좋고 밑줄은 없습니다. 그러면 [Shift] 키를 덜 사용하게 되고 손가락이 조금 게으르기 때문입니다. :)

메트로 스머프의 답변에 덧붙이기 위해서입니다.

국가 정보 교환 모델(NIEM: http://en.wikipedia.org/wiki/National_Information_Exchange_Model) )은 다음과 같이 말합니다.

• 요소에 대한 상부 낙타 케이스(PascalCase).
• (아래) 특성에 대한 낙타 대소문자.

NIEM은 표준을 준수하고자 할 때 유용한 옵션입니다.

위의 제 의견을 좀 더 자세히 설명하자면, XSLT에서 '하이픈이 있는 소문자'를 사용하는 것은 몇 가지 문제가 있습니다.구체적으로, '나이에서 나이를 뺀다'와 같은 노드를 혼동하기 쉽습니다(예: 나이에서 나이를 뺀다).

@KarlKeeninger가 지적한 바와 같이, 이것은 인간 수준의 문제일 뿐 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

위 코드에서 감산 연산자 앞에 적어도 하나의 공백을 두어야 하지만 덧셈 연산자에 대한 요구 사항은 없습니다.

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

하지만 위의 내용을 읽는 것이 얼마나 혼란스러운지 주목하세요!

<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

단일 공간이 있으면 위의 출력이 변경되지만, 두 변형 모두 오류가 아닙니다.

여러 표준에 사용되는 몇 가지 예제 규칙은 UN/CEFACT XML 이름 지정 및 설계 규칙 기술 사양 버전 3.0 페이지 23을 참조하십시오.

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

• LCC(Lower CamelCase)를 사용하여 특성 이름을 지정해야 합니다.
• UCC(Upper Camel Case)를 사용하여 요소 및 유형 이름을 지정해야 합니다.
• 요소, 속성 및 형식 이름은 개념 자체가 복수가 아닌 한 단수 형태여야 합니다.

(기타 링크, 스웨덴 사이트)

Google의 스타일 가이드는 속성 이름뿐만 아니라 모든 요소 이름에 대해 camelCase를 권장합니다.

모든 이름은 다음을 사용해야 합니다.lowerCamelCase각 새 로 시작합니다. 즉, 처음 소문자로 시작한 다음 이름의 각 새 단어는 처음 대문자로 시작합니다.

근거:단일 스타일을 채택하면 일관성이 제공되므로 대문자를 알 수 있으므로 이름을 언급할 때 도움이 됩니다.Java 스타일과 일치하며, 자동화된 이름 변환을 통해 다른 언어를 처리할 수 있습니다.

XML 케이싱의 원래 의도는 하이픈의 소문자였습니다.대소문자를 구분하기 때문에 관습을 따를 필요가 없습니다. 따라서 원하는 것을 무엇이든 할 수 있습니다.인용이 없습니다, 죄송합니다.

HTML이 대문자를 "정통적으로" 사용한다고 말하지는 않을 것입니다.원래는 HTML과 콘텐츠를 시각적으로 더 쉽게 분리하기 위해 대문자를 사용했다고 생각합니다.요즘 구문이 강조되는 상황에서는 그럴 필요가 없습니다.

필요한 경우 대시와 함께 소문자 쪽으로 방향을 전환합니다(입력 속도도 빨라짐).XML에 케이스를 섞는 것은 저에게는 단지 잘못된 것으로 느껴집니다.

낙타 사건이 내 표를 얻었소.

인용된 예에 관해서는 아마도 이 질문이 사람들이 인용하는 연결고리가 될 수 있을 것입니다.

언급URL : https://stackoverflow.com/questions/1074447/case-conventions-on-element-names