2009-03-24 2 views
12

W3의 EXI (효율적인 XML 교환)가 표준화 될 예정입니다. "마지막 바이너리 표준"이라고 주장합니다.EXI (효율적인 XML 교환) ... XML API가 준비 되었습니까?

처리 및 저장을 위해 최적화 된 XML 데이터를 저장하는 표준으로 XML 스키마가 번들로 제공됩니다 (데이터를 으로 강력하게 구조화 된 형식으로 만듭니다). 음, 많은 이점이 있다고 주장했습니다. 나는 대부분 처리에 감명을 받았으며 메모리 효율성 측정을 으로 보았습니다.

자신에게 묻는 것은, 설정된 모든 XML API에 어떤 일이 일어날 것입니까? 내 질문에 관련이 단락이

: EXI가 XML 인포 셋의 인코딩이므로

4.2 기존 XML 처리 API를

는 EXI 구현은 일반적으로 사용되는 XML 중 하나를 지원할 수 XML 처리를위한 API이므로 EXI는 기존 XML API에 즉각적인 영향을 미치지 않습니다. 그러나 기존 XML API를 사용하려면 EXI 문서에 나타나는 모든 이름과 텍스트를 문자열로 변환해야합니다. 미래에 더 높은 계층이 이러한 데이터를 EXI 문서에 나타나는 유형 값으로 직접 사용할 수 있다면 더 많은 효율성을 달성 할 수 있습니다. 예를 들어, 상위 계층에 형식화 된 데이터가 필요한 경우 문자열 형식을 사용하면 성능 저하가 발생할 수 있으므로 형식화 된 데이터를 직접 지원하는 확장 API를 사용하면 EXI와 함께 사용할 때 성능이 향상 될 수 있습니다.

부터 : http://www.w3.org/TR/exi-impacts/

나는 다음과 같은 이해 : "?! 기존의 API를 EXI를 사용 없음 성능 향상이 (당신이 그들 모두를 다시 작성하지 않는 한)"

이의 자바 생태계를 보자 없다

우리는 최신 JDK 6 에 많은 XML API를 가지고 있습니다 (각 주요 JDK 릴리스에 더 많은 것을 추가했습니다). 내가 판단 할 수있는 한 대부분의 XML 데이터는 메모리 내 DOM 트리를 사용하거나 XML 데이터를 변환/처리/유효화하기 위해 일련 번호화된 ("텍스트") 표현 을 사용하고 있습니다.

EXI가 소개 된 API에 대해 어떻게 생각하십니까?

의견을 보내 주셔서 감사합니다. EXI를 모르는 사람들을 위해

: http://www.w3.org/XML/EXI/

+0

이것은 "의견"질문을위한 장소가 아닙니다. 미안합니다. –

답변

5

EXI의 성능 향상을 얻으려면 새로운 API가 필요하지 않습니다. W3C가 수행 한 모든 EXI 테스트 및 성능 측정은 JDK에 내장 된 표준 SAX API를 사용합니다. 최신 테스트는 http://www.w3.org/TR/exi-evaluation/#processing-results을 참조하십시오. EXI 파싱은 특별한 API없이 이러한 테스트에서 XML보다 평균 14.5 배 빠릅니다.

사람들이 가치 있다고 생각하면 언젠가는 형식화 된 XML API가 나타날 수 있습니다. 그렇게되면 EXI에서 더 나은 성능을 얻을 수 있습니다. 그러나 W3C에서보고 한 것과 같은 우수한 성능을 얻으려면이 작업이 필요하지 않습니다.

2

나는 개인적으로 오히려 모든 EXI를 사용하지 것입니다. XML에 관한 모든 안좋은, 나쁜 점을 감수하고 XML (일반 텍스트 형식)의 절약 효과를 근본적으로 제거하는 이진 형식을 사용하는 것 같습니다.

업계의 일반적인 추세가 더 가벼운 데이터 전송 모델 (예 : HTTP REST)으로 이동하고 SOAP과 같은 무거운 모델에서 벗어나는 것처럼 보입니다. 개인적으로, 저는 바이너리 XML에 대한 아이디어에 흥분하지 않았습니다.

"마지막 바이너리 표준"이라고 주장하는 것은 잘못된 것입니다.

+2

그래, 나는 또한 EXI의 요점을 이해하지 못한다. 비대 해져도 XML이 사용되는 이유는 사람이 읽을 수 있기 때문입니다. XML을 가져 가면 XML은 다른 어떤 표준보다 뛰어나다. –

+3

downvote하지 않을뿐만 아니라 동의하지 않을 것입니다. 이것은 XML을 교환하는보다 효율적인 방법 일 뿐이며, over-the-wire 팽창없이 현재 형식의 모든 유연성을 허용합니다. –

+5

사실, EXI는 XML 데이터를 나타내는 또 다른 방법 일 뿐이며 일반 텍스트 XML은 이전 버전입니다. EXI를 통해 전송 된 XML 문서를 정확한 텍스트 XML 문서로 변환하는 코드를 작성하는 것은 쉽습니다. 정확히 동일한 데이터가 포함되어 있다는 것을 고려하십시오. EXI는 XML의 두 가지 주요 단점을 제거하여 크기와 처리 속도를 높이고 좋은 부분 만 남겨 둡니다. – fwielstra

4

EXI를 "XML을위한 더 나은 GZIP"로 보겠습니다. 참고로 DOM, SAX, StAX, JAXB ... 등 모든 API를 사용할 수 있으므로 API에는 아무런 영향을 미치지 않습니다. 단지 EXI를 얻으려면 스트림 라이저를 쓰거나 스트림 리더를 읽어야합니다.

EXI를 수행하는 가장 효율적인 방법은 StAX입니다. 그러나 EXI로 인해 새로운 API가 발생할 수도 있습니다. 하지만 누가 DOM이 효율적이고 잘 현대 언어를 위해 설계 되었습니까?

대용량 XML 파일을 처리하는 경우 (내가 수백 MB 정도입니다), EXI가 필요한 이유를 확실히 알고 있습니다. 톤 절약 방대한 양의 메모리와 처리 시간을 절약 할 수 있습니다.

이것은 HTTP 콘텐츠 인코딩 목적과 아무런 차이가 없습니다. 사용하지 않아도되므로 양 당사자가 이해할 경우 교환을 수행하는 것이 훨씬 효율적입니다.

덧붙여서, EXI는 SOAP가 팽창하기 때문에 HTTP IMHO를 통해 XML을 콘텐츠 인코딩하는 선호되는 방법이 될 것입니다 .-) 브라우저에서 EXI가 정해지면 모든 최종 사용자에게 이점이 될 수 있습니다. 분석 = 동일한 기계에 대한 최고의 경험!

EXI는 문자열 표현을 더 이상 사용하지 않으므로 약간 다릅니다. 아, 그런데 UTF (예를 들어 기본 UTF8로 생각할 때)를 사용하면 32 비트 유니 코드 코드 포인트에 대해 이미 "압축 인코딩"을 사용하고 있습니다 ... 이는 와이어 데이터가 실제 데이터와 동일하지 않다는 것을 의미합니다 이미 ;-)

2

EXI의 문제점은 응용 프로그램 코드에서 추상화해야한다는 것입니다. 필자는 XML의 사람이 읽을 수있는 특성이 특정 측면 (로깅, 오류 찾기 등)에서 핵심이지만 다른 영역 (I/O로드를 제한하는 내부 응용 프로그램 간의 통신)에서 희생 될 수있는 미들웨어 제품에 대해 작업합니다.

현재 클라이언트, 미들웨어 및 공급 업체 웹 응용 프로그램 간의 통신에 SOAP to를 사용합니다. 다른 영역에서 사람이 읽을 수있는 XML을 유지하면서 EXI로 바꾸고 싶습니다. EXI까지

  1. 대기가 기존 SOAP 스택 (축/SAAJ)에 통합, 또는
  2. 는 기존 축/SAAJ의 SOAP 클라이언트/공급 구현을 교체되었습니다 EXI와 SOAP 통신을 대체하기 위해 내가 하나가 필요 내 자신의 SOAP-ish와 프로토콜 위에 EXI

JSON과 EXI의 비교는 공평하지만 두 경우의 사용 사례는 다릅니다. JSON 용 메타 데이터에는 표준이 없지만 XML 용 XML 스키마는 있습니다. XML에는 특정 산업에 대한 데이터 교환을위한 스키마를 정의하는 여러 표준 기관이 있습니다. 또한 SOAP, XML 서명, XML 암호화, WS 보안, SAML 등과 같이 XML 위에 구축 된 다양한 프로토콜/표준이 있습니다. 이는 JSON에는 존재하지 않습니다.

따라서 XML은 B2B 메시지 교환 및 산업 표준을 사용하는 외부 시스템과 통합해야하는 경우에 더 나은 옵션입니다. EXI는 JSON의 이점 중 일부를이 세상에 가져올 수 있지만 널리 채택되기 전에 기존 XML API에 통합되어야합니다.

2

지금 EXI를 다루고 있습니다.

EXI를 처리하기위한 훌륭한 보편적 도구는 없습니다. 일단 당신이 EXI의 배짱에 들어갔다면, 당신은 절대적으로 그리고 완전히 스키마와 함께 불필요한 바이너리 스트림에 불필요한 구분 기호가 잔뜩 있다는 것을 깨닫게됩니다. 그것 중 일부는 유머입니다.

두 값을 모두 지정하면 다음 코드가 EXI로 인코딩된다고 어떻게 생각하십니까?

<xs:complexType name="example"> 
    <xs:sequence> 
    <xs:element name="bool1" type="xs:boolean" minOccurs="0" /> 
    <xs:element name="bool2" type="xs:boolean" minOccurs="0" /> 
    </xs:sequence> 
</xs:complexType> 

최대 4 비트라고 생각하십니까? 1 비트는 bool1이 정의되어 있는지 나타내며, bool1의 값 다음에 bool2가 정의되어 있는지 나타내는 또 다른 비트가오고 bool2의 값은?

Good golly no!

남녀별로 알려주세요. 이것이 실제로 인코딩되는 방법입니다.

+---- A value of 0 means this element (bool1) is not specified, 
|  1 indicates it is specified 
|+--- A value of x means this element is undefined, 
||  0 means the bool is set to false, 1 is set to true 
||+-- A value of 0 means this element (bool2) is not specified, 
|||  1 indicates it is specified 
|||+- A value of x means this element is undefined 
|||| 0 means the bool is set to false, 1 is set to true 
|||| 
0x0x 4 0100   # neither bools are specified 
0x10 8 00100000  # bool1 is not specified, bool2 is set to false 
0x11 8 00101000  # bool1 is not specified, bool2 is set to true 
100x 9 000000010  # bool1 is set to false, bool2 is not specified 
110x 9 000010010  # bool1 is set to true, bool2 is not specified 

1010 13 0000000000000 # bool1 is set to false, bool2 is set to false 
1011 13 0000000001000 # bool1 is set to false, bool2 is set to true 
1110 13 0000100000000 # bool1 is set to true, bool2 is set to false 
1111 13 0000100001000 # bool1 is set to true, bool2 is set to true 
     ^  ^
     +-encoding--+ 

Which can be represented with this tree 

    0-0-0-0-0-0-0-0-0-0-0-0-0 (1010) 
    \ \ \  \ \ 
    | | |  | 1-0-0-0 (1011) 
    | | |  | 
    | | |  1-0 (100x) 
    | | | 
    | | 1-0-0-0-0-0-0-0-0 (1110) 
    | |  \ \ 
    | |   | 1-0-0-0 (1111) 
    | |   | 
    | |   1-0 (110x) 
    | | 
    | 1-0-0-0-0-0 (0x10) 
    | \ 
    |  1-0-0-0 (0x11) 
    | 
    1-0-0 (0x0x) 

최소한 정의하지 않으려면 MINIMUM 이상이어야합니다. 이제 나는 조금 불공평합니다. 구분 기호를 포함하고 있기 때문입니다. 구분 기호는 완전히 불필요합니다.

나는 어떻게 작동하는지 이해합니다. 여기 사양입니다 :

https://www.w3.org/TR/exi/

재밌게가 읽기! 그것은 나를 위해 좋은 거래 !!!! @@ #! @

지금 이것은 단지 스키마와 EXI 사양은 구체적으로 당신이 여전히 스키마를 준수하지 않는 XML을 인코딩 할 수 있다고 말합니다 . 이것이 작은 웹 장치 용으로되어 있기 때문에 재미 있습니다. 임베디드 장치에서 처리 할 수있는 조항이없는 예기치 않은 데이터로 무엇을합니까?

왜, 당신은 물론 죽을 수 있습니다. 기대하지 않는 것에 대한 회복은 없습니다. 이런 것들이 화면을 가지고있는 것과는 다르다. 직렬 포트를 통해 로그인 할 수 있다면 나는 운이 좋다.

저는 4 개의 다른 XSD 생성기/파서/XML 생성기를 사용했습니다. 그들 중 3 명은 사용해야하는 스키마에 질식합니다. C 및 C++ 용 데이터 마샬링 (메모리와 CPU 성능이 거의없는 임베디드 시스템을 기억하십시오)은 끔찍합니다.

XSD는 기본적으로 구조 또는 클래스 아키텍처를 설명하며 클래스를 만드는 데 사용할 수있는 단일 도구가 없습니다. 위에 주어진 XSD 예제는 4 개의 bool, 2 개의 bool이 값이고 2 개의 bool이 정의되어 있는지 나타내는 구조를 생성해야합니다.

하지만 그게 존재합니까? 잘 됐네.

문서를 설명하기 위해 XML을 좋아합니다. 실제로 저는 XML에 대해 싫어합니다. 널리 채택 된 표준에서 사용 가능한 도구는 절대적으로 끔찍합니다. 스키마를 읽는 것은 여러 네임 스페이스와 문서에 퍼져있을 때 수행하기가 어렵습니다.

호언 장담 호언 장담, 발끈 HUF

우리는이를 사용하는 유일한 이유는 몇 가지 표준위원회는 고집이다. 이 작업은 이미이 기능을 구현 한 소규모 그룹의 회사에 독점을 제공하는 것입니다. 이것이 유일한 목적입니다.

EXI는 널리 채택 된 표준은 아니지만 XML은 수치 데이터의 캡슐화 도구로서 빈약 한 요소이며이를 구현하는 데는 어려움이 있으며 적절한 도구가 없습니다. EXIP은 5.0 버전입니다 - 오픈 소스로 작동하는 모든 것은 Java에 있습니다 - 적어도 가지고 있습니다.

내 작업 분야에서 EXI는 잘못된 설계 결정 일뿐입니다. 다양한 임베디드 시스템에서 수많은 통신 프로토콜을 연구했습니다. 저는 현대의 모든 케이블 모뎀에서 사용하는 DOCSIS를 연구했습니다. 인식 할 수없는 유형을 처리하기위한 규정과 함께 간단하고 확장 가능한 유형/길이/값 프로토콜을 사용하므로 길이가 항상 포함됩니다. 간단합니다. 전체 스택을 구현하는 데는 문자 그대로 며칠이 걸립니다.

EXI는 코드를 작성하기가 매우 어렵고, 괜찮은 프로세서가없고, 최악의 경우 모든 프로세서가 실제로 잘 작동한다는 것을 알게되었습니다. 단지 EXI < -> XML로 변환합니다. 전혀 쓸모 없어.

나는 내 자신의 XSD 파서를 작성했다. 이는 적어도이 디자인을 사용하는 부분에 대해 전체 XML 사양을 이해해야 함을 의미한다. 합리적인 사양으로 2 주간 걸렸을 때 나를 데려 갔을 것입니다. 내 세계의 어느 누구도 목구멍에 쑤셔 넣지 않고 둥근 구멍을위한 사각형의 못을 사용하지 않는 한 이걸 사용하려고하지 않습니다.