한빛출판네트워크

제공 : 한빛 네트워크
저자 : Rick Jelliffe
역자 : 추홍엽
원문 : Converting Schematron to XML Schemas, part 2

특수 용도로 XSD 프로파일을 만들기 위해 Schematron을 사용하는 것을 설명했던 Erik Wilde의 2004년 글 "Metaschema Layering for XML"을 오늘 읽어보면서, 문득 그 글이 나온지 12개월이 지나도록 Schematron 스키마를 XML 스키마로 변환하는 것에 대해 필자가 글을 쓴 적이 없었다는 것이 떠올랐다.

그 포스팅은 엘리먼트들에 대해 제약 조건들로 감싸서 선언할 수 있도록 Schematron을 구조화하여 변환을 쉽게 만드는 법에 관한 것이었다. 이 글은 좀 더 특수한(그래서 실패하기 쉬운) 접근법이다.

본 블로그의 앞선 연재에서는 이와 반대인 XML 스키마를 Schematron으로 변환하는 것에 대해 쓴 적이 있다. 당시에는 실제 개발 코드에 대해 기고한 글이었지만, 여기서는 가능한 접근법에 대해서만 간략히 설명하고자 한다.

먼저 아키텍처를 생각해 보자. 오래된 두 단계의 파이프라인에 익숙할텐데, 첫번째 단계에서는 Schematron 스키마로부터 다양한 종류의 정보를 수집하고, 두번째 단계에서는 이 정보들을 사용하여 스키마를 생성한다.

필자가 여기서 제안하는 기본 접근 방식은 단순 무식한(BFI) 패턴 매칭이다. 물론 좀 더 고수준의 정리된 로직을 사용하는 시스템을 통해 더욱 만족스러운 결과를 얻을 수도 있다.

기본적으로는 흥미로운 템플릿(Schematron은 이미 패턴이라는 용어를 사용하고 있기 때문에, 여기서는 다른 용어를 사용하겠다. 그렇다고 XSLT 템플릿을 의미하는 것은 아니다) 목록을 만들어서 규칙 컨텍스트와 평가 테스트에서 일치하는 것을 찾을 수 있도록 하겠다.

시작해 보자.

열린 스키마와 닫힌 스키마

XPath를 통해 수집해 보면 스키마 내의 모든 엘리먼트와 속성 목록을 뽑아낼 수 있다. 최악의 경우에는 이 모든 전역 선언들을 와일드 카드를 가진 컨텐트 모델로 줄 수도 있다.

만약 어떤 패턴의 마지막 규칙이 그냥 와일드 카드 "*"이고(그리고 그 이전에는 와일드 카드를 사용하는 규칙이 없었고) report 엘리먼트가 true() 테스트를 가진다면 Schematron 스키마는 닫혀 있는 것이다. 이것을 아는 것은 XSD가 완전한 것일지를 판단하는데 있어 매우 중요하다. 만약 스키마가 닫혀 있는지를 모른다면, XSD를 "lax"모드에서 유효한지 확인할 필요가 있고 마찬가지로 와일드 카드를 가진 컨텐츠들은 "lax"로서 유효할 필요가 있다.

다음과 같은 패턴이 나타날 경우, 엘리먼트의 일반적인 컨텐츠가 발견될 수 있다.

   X should have Y because blah
   
   X should one Y because blah
    

이는 XML 스키마에서 선언들을 생성하기 위해 이러한 정보가 어떻게 사용될 수 있는지를 보면 매우 명백하다. 가장 느슨한 컨텐트 모델은 단순히 다른 정보들은 가지지 않은 채, 아무거나 허용하는 느슨한 와일드 카드가 따라올 수 있다. 물론 만약 XSD 1.1이 사용된다면, 그리고 나서 초안(draft)에 있는 기능들이 통과한다면, 많은 Schematron 어써션(assertion)들을 직접적으로 XSD 어써션들로 붙이는 것이 가능해질지도 모른다!

열린 컨텐트 모델과 닫힌 컨텐트 모델

가장 중요한 것은 다음과 같이 닫힌 자식 목록을 찾는 것이다.

   X should Y and Zs only because blah
   

이러한 것들은 반복 선택 그룹이 생성되게 한다.

다음과 같이 닫힌 자식 목록이 있고 목록 내의 각각의 항목들도 한번씩만 발생한다고 한다면,

   X should one Y because blah
    
   X should one Z because blah
    
   X should Y and Zs only because blah
   

XSD의 엘리먼트를 사용하기 위한 충분한 정보를 갖는다.

주된 한계는 바로 이 단계에서 보게 된다: Schematron 스키마가 불완전할수록 XML 스키마는 작동할 수 있는 충분한 정보를 갖지 않을 가능성이 커진다. 필자는 그것이 합리적이고 직관적인 한계인 것 같다. 이것은 Schematron의 기본적으로 개방된 스키마 언어로서의 본질을 주며, 사람들은 XSD로는 잘 할 수 없는 무엇인가를 필요로 했기 때문에 구체적으로 Schematron 스키마를 사용하고 있을 수 있다. 이러한 고려를 해 볼 때, 필자는 RELAX NG가 훨씬 더 쉬워야 하기를 기대한다. 와일드 카드에 대한 다른 접근방식을 사용하여 불완전한 스키마를 허용하기 때문이다.

중복(Ditto)

필자는 여러분이 스스로 아이디어를 얻어야 할 것으로 생각한다. 나머지는 단지 디테일이다. Schematron 규칙의 종류와 XSD-to-Schematron 변환기에 의해 생성되는 어써션들은 좋은 템플릿 소스가 될 것이다. 만약 일부 어써션이 일부 속성 값에 대한 수치 테스트를 사용한다면, 그것을 그에 대한 단순한 타입을 생성하는데 사용할 수 있다. 마찬가지로 순환되는 값들에 대한 테스트는 명백히 쉽게 변환된다.

여기서 냉정하게 백만 달러짜리 질문이 생긴다. 도대체 누가 왜 이런 종류의 변환을 하려하는건가? 일반적으로 나는 진입로와 진출로에 대한 팬이다. 사람들에게 혼란을 최소한으로 주면서 기술 사이를 옮기게 하는 것 말이다(물론, 어떤 기술적 선택에 대해서는 "자업자득"에 대한 커다란 측면이 항상 있다. 시스템은 변경하기 어렵기 때문이다. 그러나 이는 기술이 그 대체 기술을 능동적으로 막을 수 있다는 것을 의미하는 것은 아니다).

내가 보는 주 용도는 이것이다. 누군가 Schematron을 사용하기로 하고 작업을 진행했다. 그러다 갑자기 누군가 달라붙어 무지몽매한 고개를 들고 말한다 우리 시스템은 (데이터 바인딩 등으로 인해) XSD가 필요하다고.

일관성 검사

첫번째 단계에서 Schematron 스키마로부터 추출해 낸 정보 종류에 대해 또 다른 용도가 예상된다. 이 단계에서는 한 스키마가 다른 더 큰 스키마를 프로파일하는데 이것은 일관성 검사 방법을 제공하기 위해 사용될 수 있다.

별것 아닌 예로, Schematron XPath에서 사용된 엘리먼트와 속성 명들은 XML 스키마에서 선언된 것들과 대응하는지 체크해 볼 수 있다. Schematron 스키마가 룰 컨텍스트 "/"를 가지고 "book"이나 "book or section" 혹은 "count(book)=1"같은 어써션을 가지고 있다면, XML 스키마는 반드시 book과 section에 대해 대응되는 전역 선언을 가져야 한다.

Schematron 스키마가 "X"같은 룰 컨텍스트를 가지고 어써션이 "count(A) + count(B) + count(C) = count(*)"와 같은 경우, X(혹은 이것의 복잡한 타입)에 대한 XML 스키마 컨텐츠 모델은 A, B, C에서 반드시 선언들을 가지고 있어야 하고, 다른 어떤 엘리먼트들도 그것들이나 일부 조상들에 대해 minOccurs=0을 가져야 한다. (intereaction은 이보다 좀 더 복잡하다. (A, B, (C, D)?)라는 컨텐츠 모델이 있고 D를 제거하는 곳에는 C도 허용하지 않는다고 가정해 보자. 이 경우, 효과적인 컨텐츠 모델은 (A, B)이다. 그러므로 엄밀히는 XML 스키마에서 C에 대한 선언은 필요가 없다.