XML은 거의 항상 오용됩니다.

XML 언어는 1996년에 발명되었습니다. 그것이 나타나자마자 그 적용 가능성이 이미 오해되기 시작했고, 그들이 그것을 적용하려는 목적에 비추어 볼 때 그것은 최선의 선택이 아니었습니다.

내가 본 대다수의 XML 스키마는 XML을 부적절하거나 올바르지 않게 사용했다고 해도 과언이 아닙니다. 더욱이 이러한 XML 사용은 XML이 무엇인지에 대한 근본적인 오해를 보여주었습니다.

XML은 마크업 언어입니다. 이것은 데이터 형식이 아닙니다.. 대부분의 XML 스키마는 이러한 구별을 명시적으로 간과하여 XML을 데이터 형식과 혼동하여 실제로 필요한 데이터 형식이기 때문에 XML을 선택하는 실수를 초래했습니다.

너무 자세히 설명하지 않고도 XML은 구조와 메타데이터로 텍스트 블록에 주석을 추가하는 데 가장 적합합니다. 주요 목표가 텍스트 블록으로 작업하는 것이 아니라면 XML을 선택하는 것이 타당하지 않을 것입니다.

이런 관점에서 XML 스키마가 얼마나 잘 만들어졌는지 확인할 수 있는 간단한 방법이 있다. 의도한 스키마의 문서를 예로 들어 모든 태그와 속성을 제거해 보겠습니다. 남은 내용이 의미가 없는 경우(또는 빈 줄이 남아 있는 경우) 스키마가 올바르게 구축되지 않았거나 단순히 XML을 사용하지 말았어야 했던 것입니다.

아래에서는 잘못 구성된 회로의 가장 일반적인 예를 몇 가지 제시하겠습니다.

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

여기에서는 XML로 간단한 키-값 사전을 표현하려는 근거가 없고 이상한(매우 일반적인) 시도의 예를 볼 수 있습니다. 모든 태그와 속성을 제거하면 빈 행이 남게 됩니다. 본질적으로 이 문서는 아무리 터무니없이 들리더라도 빈 줄에 대한 의미론적 주석입니다.

<root name="John" city="London" />

설상가상으로, 사전을 표현하는 사치스러운 방법으로 여기에 빈 문자열의 의미 주석이 있는 것이 아닙니다. 이번에는 "사전"이 루트 요소의 속성으로 직접 인코딩됩니다. 이는 요소의 지정된 속성 이름 세트를 정의되지 않고 동적으로 만듭니다. 또한 저자가 실제로 표현하고 싶었던 것은 단순한 키-값 구문이었지만 그 대신 XML을 적용하기로 한 완전히 기괴한 결정을 내려 속성 구문을 사용하기 위한 접두사로 단일 빈 요소를 사용하도록 강요했습니다. 그리고 저는 그러한 계획을 자주 접합니다.

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

이것은 더 나은 것이지만 이제 어떤 이유로 키는 메타데이터이고 값은 그렇지 않습니다. 사전을 보면 매우 이상합니다. 모든 태그와 속성을 제거하면 정보의 절반이 손실됩니다.

XML의 올바른 사전 표현식은 다음과 같습니다.

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

그러나 사람들이 XML을 데이터 형식으로 사용하고 이를 어휘 구성에 사용하기로 이상한 결정을 내렸다면 자신이 하고 있는 작업이 부적절하고 편리하지 않다는 것을 이해해야 합니다. 또한 디자이너가 응용 프로그램을 만들 때 실수로 XML을 선택하는 경우도 많습니다. 그러나 훨씬 더 자주 그들은 XML이 단순히 여기에 적합하지 않다는 사실을 무시하고 위에 설명된 형식 중 하나로 XML을 무의미하게 사용함으로써 상황을 더욱 악화시킵니다.

최악의 XML 스키마? 그건 그렇고, 상금은 내가 본 최악의 XML 스키마, Polycom IP 전화 통신용 자동 프로비저닝 구성 파일 형식을 가져옵니다. 이러한 파일에는 TFTP를 통해 XML 요청 파일을 다운로드해야 합니다. 일반적으로 다음은 해당 파일 중 하나에서 발췌한 것입니다.

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

이것은 누군가의 나쁜 농담이 아닙니다. 그리고 이것은 내 발명품이 아닙니다.

• 요소는 단순히 속성을 첨부하기 위한 접두사로 사용되며, 속성 자체에는 계층적 이름이 있습니다.
• 특정 레코드 유형의 여러 인스턴스에 값을 할당하려면 속성 이름을 사용해야 합니다. 인덱스가 있는 것.
• 또한 다음으로 시작하는 속성은 softkey., 요소에 배치해야 합니다. <softkey/>, 다음으로 시작하는 속성 feature., 요소에 배치해야 합니다. <feature/> 등, 완전히 불필요하고 언뜻보기에는 의미가 없어 보이지만.
• 그리고 마지막으로 속성 이름의 첫 번째 구성 요소가 항상 요소 이름과 동일하기를 바랐다면 그런 것은 없습니다! 예를 들어 속성 up. 에 첨부해야 합니다. <userpreferences/>. 요소에 속성 이름을 첨부하는 순서는 임의적이며 거의 완벽합니다.

문서 또는 데이터. 때때로 누군가 XML과 JSON을 비교하여 완전히 이상한 일을 하여 둘 중 하나도 이해하지 못한다는 것을 보여줍니다. XML은 문서 마크업 언어입니다. JSON은 구조화된 데이터 형식이므로 서로 비교하는 것은 따뜻한 것과 부드러운 것을 비교하려는 것과 같습니다.

차이점의 개념 문서와 데이터. XML과 유사하게 기계가 읽을 수 있는 문서를 조건부로 가져올 수 있습니다. 기계가 읽을 수 있도록 의도되었지만 은유적으로는 문서를 의미하며 이러한 관점에서 볼 때 실제로 기계가 읽을 수 없는 경우가 가장 많은 PDF 문서와 유사합니다.

예를 들어 XML에서는 요소의 순서가 중요합니다. 그러나 JSON에서는 객체 내 키-값 쌍의 순서가 의미가 없고 정의되지 않습니다. 키-값 쌍의 순서가 지정되지 않은 사전을 얻으려는 경우 해당 파일에 요소가 나타나는 실제 순서는 중요하지 않습니다. 하지만 이 데이터로부터 다양한 유형의 데이터를 형성할 수 있습니다. 서류, 문서에는 특정 순서가 있기 때문입니다. 인쇄물이나 PDF 파일과 달리 물리적 크기는 없지만 은유적으로 종이에 적힌 문서와 유사합니다.

적절한 XML 사전 표현의 예는 JSON 표현과 반대로 사전의 요소 순서를 보여줍니다. 나는 이 순서를 무시할 수 없습니다. 이 선형성은 문서 모델과 XML 형식에 내재되어 있습니다. 어떤 사람들은 이 XML 문서를 해석할 때 순서를 무시하기로 선택할 수도 있지만, 이 문제는 형식 자체에 대한 논의 범위를 벗어나므로 이에 대해 논쟁할 필요는 없습니다. 더욱이, CSS 스타일 시트를 문서에 첨부하여 브라우저에서 문서를 볼 수 있도록 하면 사전 요소가 특정 순서로만 나타나는 것을 볼 수 있습니다.

즉, 사전(구조화된 데이터 조각)은 다음과 같이 변환될 수 있습니다. n 다양한 가능한 문서(XML, PDF, 종이 등) n - 사전에 있는 요소의 가능한 조합 수이며 다른 가능한 변수는 아직 고려하지 않았습니다.

그러나 데이터만 전송하려는 경우 기계 판독 가능한 문서를 사용하는 것은 효과적이지 않습니다. 이 경우 불필요한 모델을 사용하므로 방해가 될 뿐입니다. 또한 원본 데이터를 추출하려면 프로그램을 작성해야 합니다. 어느 시점에서 문서 형식이 지정되지 않는 항목(예: CSS나 XSLT 또는 둘 다 사용)에 대해 XML을 사용하는 것은 거의 의미가 없습니다. 왜냐하면 그것이 유일한 이유는 아니지만 주된 이유이기 때문입니다. 문서 모델에.

더욱이 XML에는 숫자(또는 부울 표현식 또는 기타 데이터 유형) 개념이 없으므로 이 형식으로 표현된 모든 숫자는 단지 추가 텍스트로 간주됩니다. 데이터를 추출하려면 스키마와 표현되는 해당 데이터와의 관계를 알아야 합니다. 또한 상황에 따라 특정 텍스트 요소가 숫자를 나타내고 숫자로 변환되어야 하는 경우도 알아야 합니다.

따라서 XML 문서에서 데이터를 추출하는 과정은 예를 들어 많은 페이지의 숫자 데이터를 구성하는 테이블을 포함하는 스캔된 문서를 인식하는 과정과 크게 다르지 않습니다. 예, 원칙적으로는 가능하지만 다른 옵션이 전혀 없는 최후의 수단을 제외하고는 이것이 가장 최적의 방법은 아닙니다. 합리적인 해결책은 데이터를 특정 텍스트 표현과 결합하는 문서 모델에 포함되지 않은 원본 데이터의 디지털 복사본을 찾는 것입니다.

즉, XML이 비즈니스에서 널리 사용된다는 사실은 전혀 놀랍지 않습니다. 그 이유는 바로 문서 형식(종이)이 비즈니스에 이해하기 쉽고 친숙하며, 친숙하고 이해하기 쉬운 모델을 계속 사용하기를 원하기 때문입니다. 같은 이유로 기업에서는 기계가 읽을 수 있는 형식 대신 PDF 문서를 사용하는 경우가 너무 많습니다. 이는 여전히 특정 물리적 크기의 인쇄된 페이지 개념에 묶여 있기 때문입니다. 이는 인쇄될 가능성이 거의 없는 문서(예: 레지스트리 문서의 8000페이지 PDF)에도 적용됩니다. 이러한 관점에서 볼 때 비즈니스에서 XML을 사용하는 것은 본질적으로 스큐어모피즘의 표현입니다. 사람들은 제한된 크기의 인쇄된 페이지에 대한 은유적 아이디어를 이해하고, 인쇄된 문서를 기반으로 비즈니스 프로세스를 생성하는 방법을 이해합니다. 그것이 여러분의 가이드라면 기계가 읽을 수 있는 물리적 크기 제한이 없는 문서(XML 문서)는 익숙하고 편안한 문서 사본이면서 혁신을 나타냅니다. 이는 데이터를 표시하는 부정확하고 지나치게 스큐어모픽적인 방식으로 남아 있는 것을 방지하지 못합니다.

현재까지 내가 알고 있는 형식의 유효한 사용이라고 할 수 있는 유일한 XML 스키마는 XHTML과 DocBook입니다.

출처 : habr.com