문제

C ++ 응용 프로그램은 다음과 같은 모습을 보이는 XML 파일의 구성 데이터를 읽습니다.

<data>
 <value id="FOO1" name="foo1" size="10" description="the foo" ... />
 <value id="FOO2" name="foo2" size="10" description="the other foo" ... />
 ...
 <value id="FOO300" name="foo300" size="10" description="the last foo" ... />
</data>

완전한 응용 프로그램 구성은이 XML 파일 중 ~ 2500 (150 만 개 이상의 키/값 속성 쌍으로 변환)으로 구성됩니다. XML 파일은 여러 다른 소스/팀에서 제공되며 스키마에 대해 검증됩니다. 그러나 때로는 <value/> 노드는 다음과 같습니다.

<value name="bar1" id="BAR1" description="the bar" size="20" ... />

아니면 이거:

<value id="BAT1" description="the bat" name="bat1"  size="25" ... />

이 프로세스를 빠르게 만들기 위해 우리는 사용 중입니다 국외 거주자 XML 문서를 구문 분석합니다. 국외 거주자는 속성을 배열로 노출시킵니다.

void ExpatParser::StartElement(const XML_Char* name, const XML_Char** atts)
{
 // The attributes are stored in an array of XML_Char* where:
 //  the nth element is the 'key'
 //  the n+1 element is the value
 //  the final element is NULL
 for (int i = 0; atts[i]; i += 2) 
 {
  std::string key = atts[i];
  std::string value = atts[i + 1];
  ProcessAttribute (key, value);
 }
}

이것은 모든 책임을 우리에게 제공합니다 ProcessAttribute() '키'를 읽고 값으로 무엇을 해야하는지 결정하십시오. 앱 프로파일 링은 총 XML 파싱 시간의 ~ 40%가 이름/문자열로 이러한 속성을 다루고 있음을 보여주었습니다.

속성 순서를 보장/시행 할 수 있다면 전체 프로세스가 급격히 증가 할 수 있습니다 (스타터의 경우 문자열 비교 없음 ProcessAttribute()). 예를 들어, 'ID'속성 인 경우 언제나 우리가 직접 처리 할 수있는 첫 번째 속성 :

void ExpatParser::StartElement(const XML_Char* name, const XML_Char** atts)
{
 // The attributes are stored in an array of XML_Char* where:
 //  the nth element is the 'key'
 //  the n+1 element is the value
 //  the final element is NULL
 ProcessID (atts[1]);
 ProcessName (atts[3]);
 //etc.
}

W3C 스키마 사양에 따르면 <xs:sequence> XML 스키마에서 요소의 순서를 시행 할 수 있지만 속성에 대해서는 작동하지 않는 것 같습니다. 또는 아마도 잘못 사용하고 있습니다.

<xs:element name="data">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="value" type="value_type" minOccurs="1" maxOccurs="unbounded" />
  </xs:sequence>
 </xs:complexType>
</xs:element>

<xs:complexType name="value_type">
 <!-- This doesn't work -->
 <xs:sequence>
  <xs:attribute name="id" type="xs:string" />
  <xs:attribute name="name" type="xs:string" />
  <xs:attribute name="description" type="xs:string" />
 </xs:sequence>
</xs:complexType>

XML 문서에서 속성 순서를 시행하는 방법이 있습니까? 대답이 "아니오"인 경우 - 누군가가 거대한 런타임 성능 페널티를받지 않는 대안을 제안 할 수 있습니까?

도움이 되었습니까?

해결책

XML 사양에 따르면

시작 태그 또는 빈 요소 태그의 속성 사양 순서는 중요하지 않습니다.

당신은 그것을 확인할 수 있습니다 섹션 3.1

다른 팁

XML 속성은 그렇지 않습니다 가지다 따라서 명령이므로 시행 할 명령이 없습니다.

주문을 원한다면 XML 요소가 필요합니다. 또는 XML과 다른 것. JSON, YAML 및 BENCODE, 예를 들어, 예를 들어 맵 (정렬되지 않은)과 시퀀스 (주문)가 모두 있습니다.

다른 사람들이 지적했듯이, 당신은 속성 순서에 의존 할 수 없습니다.

2,500 개의 XML 파일과 150 만 개의 키/값 쌍이 포함 된 프로세스가 있다면 해당 데이터를 XML에서 최대한 빨리 사용 가능한 형태로 가져옵니다. 데이터베이스, 이진 직렬화 형식 등. XML을 사용하여 스키마 검증 이외의 이점을 얻지 못합니다. 새로운 XML 파일을 얻을 때마다 매장을 업데이트하고 프로세스의 주요 흐름에서 150 만 XML 요소를 파싱합니다.

대답 ~이다 아아. 나는 당신의 40% 수치에 충격을 받았습니다. 나는 "foo"를 ProcessFoo로 바꾸는 것이 오래 걸린다 고 믿기가 어렵다는 것을 알게됩니다. 40%가 시간을 포함하지 않는다고 확신합니까? 실행하다 Processfoo?

이 외국인을 사용하여 이름으로 속성에 액세스 할 수 있습니까? 그것은 속성에 액세스하는 더 전통적인 방법입니다. 나는 그것이 더 빠를 것이라고 말하지는 않지만 시도해 볼 가치가있을 것입니다.

XML 스키마 가이를 지원한다고 생각하지 않습니다. 속성은 이름으로 방금 정의되고 제한되어 있습니다. 예를 들어 특정 이름과 일치해야합니다. 그러나 XSD에서 해당 속성에 대한 순서를 어떻게 정의 할 수 있는지 알 수 없습니다.

XML 노드의 속성이 특정 순서로 오는지 확인하는 다른 방법을 모릅니다. Schematron 또는 Relation과 같은 다른 XML 스키마 메커니즘이이를 지원할 것인지 확실하지 않습니다 ....

XML 문서에서 속성 순서를 시행 할 방법이 없다고 확신합니다. 비즈니스 프로세스 나 계약 또는 기타 문서와 같은 기타 인적 요소를 통해 주장 할 수 있다고 가정하겠습니다.

첫 번째 속성이 "ID"라고 가정하고 이름을 확실히 테스트했다면 어떨까요? 그렇다면 값을 사용하십시오. 그렇지 않은 경우 이름으로 속성을 가져 오거나 문서를 버릴 수 있습니다.

서수에 의해 속성을 호출하는 것만 큼 효율적이지는 않지만, 일부 0이 아닌 횟수는 데이터 제공 업체가 XML을 SPEC에 전달했다고 추측 할 수 있습니다. 나머지 시간에는 다른 조치를 취할 수 있습니다.

추측 만하지만 추가 해보십시오 use="required" 각 속성 사양에?

<xs:complexType name="value_type">
 <!-- This doesn't work -->
 <xs:sequence>
  <xs:attribute name="id" type="xs:string" use="required" />
  <xs:attribute name="name" type="xs:string" use="required" />
  <xs:attribute name="description" type="xs:string" use="required" />
 </xs:sequence>
</xs:complexType>

선택적 속성을 허용하여 파서가 속도가 느려지는지 궁금합니다. 속성이 항상있을 때 나타납니다.

다시 한 번 추측.

편집하다: XML 1.0 사양에 따르면 속성 순서는 중요하지 않다고 말합니다. http://www.w3.org/tr/rec-xml/#sec-starttags

따라서 XSD는 주문을 시행하지 않습니다. 그러나 그렇다고 구문 분석기가 빨리 일하는 데 속을 수 없다는 것을 의미하지는 않기 때문에 실제로 작동하는 경우 위의 답변을 게시하고 있습니다.

내가 기억하는 바에 따르면, 국외 거주자는 유효성이없는 파서이며 더 나은 것입니다. 따라서 XSD 아이디어를 스크랩 할 수 있습니다. 많은 XML 접근 방식에서 주문 의존적이 좋은 아이디어도 아니다 (예를 들어 MSFT에서 XML 웹 서비스의 프로 또는 XML 웹 서비스의 프로 또는 판매자에 의해 XSD는 요소 주문에 대해 많은 비판을 받았다.

사용자 정의 인코딩을 수행하고보다 효율적인 조회를 위해 논리를 확장하거나 파서 소스를 파헤칩니다. 소프트웨어 에이전트와 사용자를 보호하는 동안 효율적인 교체를 인코딩하는 데 툴링을 작성하는 것은 중요합니다. 소프트웨어 에이전트와 사용자를 차폐하여이를 수행하려면 뒤로 호환성과 가역성을 보존하면서 쉽게 마이그레이션됩니다. 또한 고정 크기 제약 조건/속성-이름 변환을 찾으십시오.

국외 거주자로 운이 좋다고 생각하십시오 :) 그리고 그 원시 속도. CLR Devs가 XML 스케일링 시설을 좋아하는 방법을 상상해보십시오. '데이터베이스를 쿼리하는 것만으로 도와서 와이어로 200MB를 전송합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top