KR100836350B1 - Ｘｍｌ 도큐먼트들의 효율적인 관리를 위한 방법 및 장치 - Google Patents

Abstract

인-메모리 스토리지 매니저는 XML-컴플라이언트 도큐먼트들을 메모리 내의 객체들의 집합으로서 표현한다. 객체들의 집합은 스토리지 매니저가 일치하는 인터페이스를 갖고 도큐먼트 또는 도큐먼트의 부분들을 조작하고 텍스트가 아닌 타입들을 갖는 엘리먼트 속성들 및 텍스트 정보가 아닌 이진수를 포함하는 도큐먼트들과 같은 종래의 XML 도큐먼트들에서 이용 가능하지 않은 특징들을 제공할 수 있게 한다. 스토리지 매니저에서, XML-컴플라이언트 도큐먼트는 도큐먼트 엘리먼트들 및 속성들의 배열을 정의하는 스키마 도큐먼트와 연관된다. 이 스키마 데이터는 도큐먼트 엘리먼트들과 각각의 엘리먼트와 연관되는 프로그램 코드 사이의 맵핑을 포함할 수 있는 도큐먼트와 연관된다. 스토리지 매니저는 엘리먼트 태그로부터 코드를 검색하기 위한 방법들을 더 포함한다. 다음에 검색된 코드는 연관된 엘리먼트로부터의 속성들 및 콘텐츠를 사용하여 호출될 수 있으며 엘리먼트는 종래의 객체들과 같이 동작한다. 또한, 스토리지 매니저는 상이한 컨텍스트들에서 동작하는 개별적인 프로세스에 의해 실시간 억세스를 가능하게 한다. 도큐먼트를 표현하는 데 사용되는 객체들은 각각의 프로세스에서 지역적으로 발견되는 공통 코드로부터 구성된다. 로컬 메모리는 상이한 프로세들에서 동일한 엘리먼트의 데이터 카피들을 연속적으로 동등하게 되는 분산 메모리 시스템에 의해 동기된다. 클라이언트 특정된 집합들은 새별적인 집합 매니저에 의해 관리된다. 집합 매니저는 테이블 형태로 XML 데이터 구조를 표현하는 데이터 구조, 소위 "와플"을 유지한다. 사용자 명령들에 의해 구동되는 레코드 세트 엔진은 집합을 위한 업데이트 세트를 집합 매니저로 전달한다. 이러한 업데이트를 기초로 하여, 집합 매니저는 인덱스 구조들을 갖고 통지 시스템을 통해 와플 사용자들에게 통지할 수 있다.

XML, SGML, HTML, 브라우저, 도큐먼트, 윈도우즈

Description

ＸＭＬ 도큐먼트들의 효율적인 관리를 위한 방법 및 장치{METHOD AND APPARATUS FOR EFFICIENT MANAGEMENT OF XML DOCUMENTS}

본 발명은 정보의 저장 및 검색, 특히 확장성 표시 언어(Extended Markup Language : XML)로 엔코딩된 정보의 저장 및 검색에 관한 것이다.

현대의 컴퓨팅 시스템은 다량의 데이터를 저장, 검색, 및 관리할 수 있다. 그러나, 컴퓨터가 수치 데이터 취급에 있어서는 빠르고 효율적이지만 텍스트 데이터를 조작하는 데 있어서는 비효율적이며 인간이 판독 가능한 텍스트 데이터를 번역하는 데 있어서 특히 빈약하다. 일반적으로 오늘날의 컴퓨터는 인간이 판독 가능한 텍스트 도큐먼트를 포함하는 정보의 단편을 이해하고 인지하기 위해 필요한 미묘한 문맥 정보를 이해하지 못한다. 따라서, 획일적인 텍스트 도큐먼트 내의 단어들과 같은 소정의 텍스트 배열 또는 부분들을 검출할 수 있지만, 정보를 정의하는 단어 또는 단어들이 특정한 의미를 갖는 곳에 정보의 특정한 부분을 로케이트할 수는 없다. 예를 들어, 인간은 문장 "The attorney will read the text of Mark's will."에서 단어 "will"을 구별하는 데 어려움이 없지만, 컴퓨터는 2가지 용도를 구별하여 단지 두 번째 용도만을 로케이트하는 것이 어려울 수 있다.

그러므로, 컴퓨터가 적절한 도큐먼트 코딩에 의해 텍스트 도큐먼트를 번역하는 것을 돕기 위한 기법이 개발되었다. 이러한 여러 기법들은 컴퓨터가 신뢰할 수 있게 정보를 인식할 수 있도록 하는 방식으로 상이한 도큐먼트 부분들을 구별하는 도큐먼트 정보, 소위 "마크업 태그(markup tags)"를 추가함으로써 텍스트 도큐먼트의 선택된 부분들을 식별한다. 이러한 기법을 일반적으로 "마크업" 언어("markup" language)라고 한다.

이러한 언어들 중 하나는 소위 SGML(일반화된 표준 마크업 언어 : Standard Generalized Markup Language)이며 정보 표현을 위해 국제적으로 승인되어 있다. 이러한 언어 표준은 1970초에 수행되었던 일반적 코딩 및 마크업 언어의 개발 작업에서 이루어지게 되었다. 다양한 연구 라인들이 국제 표준 기구의 소위원회, 소위 텍스트 기술 및 처리 언어에 대한 소위원회로 병합되었다. 이러한 소위원회는 1986년에 SGML 표준을 제정하였다.
SGML 그 자체는 마크업 태그를 정의하지도 도큐먼트의 특정한 형태에 대한 마크업 템플릿(template)을 제공하지도 않는다는 면에서 마크업 언어가 아니다. 대신에, SGML은 일반화된 디스크립션 마크업 기법들을 기술하고 개발하는 방법을 나타내고 있다. 이러한 기법들은 마크업이 특정한 어플리케이션을 지향하지 않기 때문에 일반화되며 텍스트가 어떻게 표시되어야 하는지 대신에 텍스트가 나타내는 것을 마크업이 기술하기 때문에 기술적이다. SGML은 표준에 따라 기입된 마크업 기법들이 사용자가 도큐먼트들을 위한 그 자신의 포맷들을 정의하고, 크고 복잡한 도큐먼트들을 취급하며, 대규모 정보 저장소를 관리하도록 한다는 면에서 매우 유연하다.

삭제

최근에, 다른 발전이 일반적인 상황을 변화시키고 있다. 인터넷의 경이적인 성장, 특히, 월드 와이드 웹은 저자, 또는 콘텐츠 제공자가 쉽고 저렴하게 전자 도큐먼트들을 전세계적인 독자에게 배포하는 능력에 의해 드라이브되었다. SGML은 웹 기반 어플리케이션을 위해 요구되지 않는 많은 선택적인 특징들을 포함하며 웹 브라우저의 현재의 벤더들에 매력적이지 않은 비용/이익 비율을 갖고 있음이 입증되었다. 따라서, 일반적으로 사용되지 않고 있다. 대신에, 웹 상의 대부분의 도큐먼트들은 하이퍼 텍스트 마크업 언어 또는 HTML로 불리는 마크업 언어로 저장 및 전송된다.

HTML은 SGML 기반의 간단한 마크업 언어이며 하이퍼텍스트, 멀티미디어, 및 웹 상에서 일반적으로 전송되는 작고 상당히 간단한 도큐먼트들의 표시에 적합하다. HTML은 작고, 고정된 세트의 마크업 태그들을 사용하여 도큐먼트 부분들을 기술한다. 소수의 고정된 태그들은 도큐먼트 구성을 간소화하며 어플리케이션 구축을 훨씬 용이하게 한다. 그러나, 태그들이 고정되어 있으므로, HTML은 확장 가능하지 않으며 매우 제한된 구조 및 유효 능력을 가지고 있다. 전자 웹 도큐먼트들이 보다 커지고 복잡해짐에 따라, HTML은 대규모의 상업적인 간행을 위해 요구되는 능력을 가지고 있지 않음이 점차 명백해지게 되었다.

이러한 대규모의 상업적인 간행의 요구에 부응하고 분산된 도큐먼트 처리의 새로운 기술을 가능하게 하기 위해, 산업 단체, 소위 월드 와이드 웹 컨소시엄은 HTML에 의해 제공되는 것 이상의 능력을 필요로 하는 어플리케이션들을 위한 다른 마크업 언어, 소위 확장 가능한 마크업 언어(XML)를 개발하였다. HTML과 같이, XML은 웹 어플리케이션들을 위해 특별히 설계된 SGML의 간소화된 서브셋이며 전체 SGML보다 습득, 사용, 및 구현하기가 용이하다. HTML과 달리, XML은 SGML의 장점인 확장성, 구조, 및 유효성을 유지하였지만, XML은 도큐먼트의 일정한 컴포넌트들에 대한 억세스가 인터넷을 통해 현재 가능하지 않을 때 디폴트가 유효한 것을 보장하도록 SGML 구성의 사용을 제한한다. 또한, XML은 인터넷 유니폼 리소스 로케이터(Uniform Resource Locators)가 어떻게 XML 도큐먼트들의 컴포넌트 부분들을 식별하는 데 사용될 수 있는 지를 정의하고 있다.

XML 도큐먼트는 일련의 실체(entities) 또는 객체(object)로 구성된다. 각각의 실체는 하나 이상의 논리적인 엘리먼트를 포함할 수 있으며 각각의 엘리먼트는 그것이 처리되는 방식을 기술한 임의의 속성 또는 특성을 가질 수 있다. XML은 XML 도큐먼트를 구성하는 실체들, 엘리먼트들, 및 속성들 사이의 관계를 기술하기 위해 형식적인 구문(syntax)을 제공한다. 이러한 구문은 컴퓨터에게 각각의 도큐먼트의 컴포넌트 부분들을 어떻게 인식할 지를 제공한다.

XML은 도큐먼트 컴포넌트들을 식별하는 쌍으로 된 마크업 태그들을 사용한다. 특히, 각각의 논리적인 엘리먼트의 시작 및 말단이 엘리먼트 이전의 시작 태그 및 엘리먼트 후의 말단 태그의 입력에 의해 명확히 식별된다. 예를 들어, 태그 <to> 및 </to>는 다음의 방식으로 문서의 "recipient" 엘리먼트를 식별하는 데 사용될 수 있다.

document text ... <to>Recipient</to> ... document text

마크업 태그들의 형태 및 구성은 사용자에 의해 정의될 수 있지만, 종종 사용자들 간의 상호 이용성을 제공하기 위해 무역 협회 또는 유사 단체에 의해 정의된다. 소정의 세트의 태그들로 동작하기 위해, 사용자들은 마크업 태그들이 통상적인 텍스트 및 다양한 엘리먼트들 간의 관계로부터 어떻게 범위가 결정되는 지를 알 필요가 있다. 예를 들어, XML 시스템에서, 엘리먼트들 및 그 속성들은 꺾쇠 괄 호 (<...>)의 일치된 쌍들 사이에 입력되며, 실체 레퍼런스들은 앰퍼샌드로 시작하여 세미콜론(&...;)으로 끝난다. XML 태그 세트들은 도큐먼트의 논리적인 구조에 기반하기 때문에, 이들은 판독하고 이해하기 쉽다.

상이한 도큐먼트들은 상이한 부분들 또는 컴퍼넌트들을 가지므로, 모든 도큐먼트들의 모든 엘리먼트들에 대해 태그들을 미리 정의하는 것은 실용적이지 않다. 대신에, 도큐먼트들은 일정한 엘리먼트들을 갖는 "타입(types)"으로 분류될 수 있다. 도큐먼트 타입 정의(DTD)는 어느 엘리먼트가 도큐먼트 타입으로 예상되는 지를 나타내며 도큐먼트에서 발견된 각각의 엘리먼트가 허용되는 지, 허용되고 요구되는 지, 또는 허용되지만 요구되지 않는 지를 나타낸다. DTD 내의 각각의 도큐먼트 엘리먼트의 역할을 정의함으로써, 각각의 엘리먼트가 도큐먼트 내의 유효 위치에서 발생하는 지를 검사하는 것이 가능하다. 예를 들어, XML DTD는 제2 레벨 표제(heading)의 존재 없이 제3 레벨 표제가 입력되지 않도록 검사가 이루어지도록 한다. 이러한 계층적인 검사는 HTML로는 이루어질 수 없다. 도큐먼트에 대한 DTD는 전형적으로 도큐먼트 헤더에 삽입되며 각각의 엘리먼트는 <!ELEMENT>와 같은 식별자로 마킹된다.

그러나, SGML과 달리, XML은 DTD의 존재를 필요로 하지 않는다. DTD의 전부 또는 일부가 인터넷을 통해 억세스 가능하지 않거나 또는 도큐먼트 저자가 DTD를 생성하는 데 실패했기 때문에, 어떤 DTD도 도큐먼트에 대해 이용 가능하지 않다면, XML 시스템이 도큐먼트 내에서 선언되지 않은 엘리먼트들에 대한 디폴트 정의를 할당할 수 있다.

XML은 서신, 보고서, 메모, 데이터베이스, 또는 사전과 같은 거의 모든 논리적인 텍스트 구조를 기술하기에 충분히 유연한 코딩 기법을 제공한다. 그러나, XML은 XML-컴플라이언트 데이터 구조가 어떻게 저장되고 표시되는 지를 특정하지 않아서, 훨씬 덜 효율적으로 저장 및 표시된다. 따라서, XML 컴플라이언트 도큐먼트들을 효율적으로 조작 및 저장할 수 있는 저장 메카니즘이 필요하다.

본 발명의 실시예에 따르면, 인-메모리 스토리지 매니저(in-memory storage manager)는 XML-컴플라이언트 데이터 도큐먼트를 메모리 내에 객체들의 집합으로서 나타낸다. 객체들의 집합은 스토리지 매니저가 일치하는 인터페이스로 도큐먼트 또는 도큐먼트의 부분들을 조작하여 텍스트가 아닌 이진 정보를 포함하는 텍스트 및 도큐먼트들과 다른 형태를 갖는 엘리먼트 속성들과 같은 종래의 XML 도큐먼트들에서 이용 가능하지 않은 특징들을 제공한다. 또한 스토리지 매니저에서, XML-컴플라이언트 도큐먼트는 도큐먼트 엘리먼트들 및 속성들의 배열을 정의하는 스키마 도큐먼트(또한, XML 도큐먼트임)와 연관된다. 스토리지 매니저는 XML-컴플라이언트 도큐먼트를 지속시키도록 종래의 스토리지 서비스들과 함께 동작할 수 있다. 스토리지 컨테이너는 스토리지 매니저에 의해 신속하게 로케이트될 수 있는 도큐먼트의 단편들을 포함한다.

다른 실시예에 따르면, 스토리지 매니저는 또한 일치하는 방식으로 도큐먼트 콘텐츠의 엘리먼트들 및 속성들을 억세스 및 조작하도록 하는 소정의 방법들을 갖는다. 예를 들어, 스키마 데이터는 도큐먼트 콘텐츠를 억세스 및 조작하는 데 사용되는 것과 동일한 방법들로 억세스 및 조작될 수 있다.

다른 실시예에 따르면, 도큐먼트와 연관된 스키마 데이터는 도큐먼트 엘리먼트들과 각각의 엘리먼트와 연관되는 프로그램 코드 사이의 맵핑을 포함할 수 있다. 스토리지 매니저는 엘리먼트 태그로부터 코드를 검색하기 위한 방법들을 더 구비한다. 다음에 검색된 코드는 연관된 엘리먼트로부터의 속성들 및 콘텐츠를 사용하여 호출될 수 있으며 다음에 엘리먼트는 종래의 객체와 같이 동작한다.

모든 실시예들에서, 스토리지 매니저는 다중 컨텍스트(multiple contexts) 내의 다중 프로세스들에 의해 클라이언트들에 대한 동적, 실시간 데이터 억세스를 제공한다. 동일한 도큐먼트를 억세스하는 다중 프로세스들 사이의 동기화는 이벤트-구동 큐 및 락으로 일치된다. 도큐먼트를 표현하는 데 사용된 객체들은 각각의 프로세스에서 국부적으로 발견된 공통 코드로부터 생성된다. 또한, 객체들 내의 데이터는 각각의 프로세스의 로컬 메모리에 저장된다. 로컬 메모리들은 상이한 프로세스들에서 동일한 엘리먼트의 데이터 카피들을 끊임없이 같게 만드는 분산 메모리 시스템에 의해 동기화된다.

또 다른 실시예에서, 클라이언트-특정 집합은 개별적인 집합 매니저에 의해 관리된다. 집합 매니저는 테이블 형태로 XML 데이터 구조들을 표현하는 데이터 구조, 소위 "와플(waffle)"을 유지한다. 사용자 명령에 의해 구동되는 레코드 세트 엔진은 집합을 위한 업데이트 세트를 집합 매니저에 전달한다. 이러한 업데이트들을 기초로, 집합 매니저는 인덱스 구조들을 업데이트하고 통지 시스템을 통해 와플 사용자들(waffle users)에게 통지할 수 있다. 와플 사용자는 또한 커서를 사용하여 집합 내에서 탐색할 수 있다.

본 발명의 상기와 같은 장점들 및 다른 장점들은 첨부된 도면과 함께 다음의 설명을 참조함으로써 보다 완전히 이해될 것이다.

도 1은 본 발명의 스토리지 매니저 시스템이 동작할 수 있는 컴퓨터 시스템의 개략도이다.

도 2는 인-메모리 스토리지 매니저와 영구적 스토리지의 관계를 도시한 개략적인 블럭도이다.

도 3은 스토리지 매니저 메모리상의 XML 도큐먼트의 표현을 객체들의 집합으로서 도시한 개략적인 블럭도이다.

도 4A는 XML 엘리먼트들에 코드를 바인딩하는데 관련된 컴포넌트들을 도시한 개략적인 블럭도이다.

도 4B는 엘리먼트에 바인드된 프로그램 코드 검색에 관련된 단계들을 도시한 플로우 차트이다.

도 5는 XML 텍스트 도큐먼트들과 이진 서브도큐먼트들의 관계를 도시한 도면이다.

도 6은 상이한 프로세스들 내의 스토리지 매니저의 주요 내부 부분들을 도시한 개략적인 블럭도이다.

도 7은 프로세스들 전반에 걸친 객체들을 동기화시키기 위한 메카니즘을 도시하고 있다.

도 8은 스토리지 매니저 API들로부터 스토리지 매니저의 주요 내부 부분들에 이르는 주 제어 경로들을 도시한 도면이다.

도 9는 본 발명의 객체 지향 구현에 따라 구성된 스토리지 매니저 인터페이스를 도시한 도면이다.

도 10은 스토리지 매니저에 의해 정의되며 링크 또는 엘리먼트 RPC들의 프로세싱 동안에 호출될 수 있는 본 발명의 객체-지향 구현에 따라 구성된 인터페이스들을 도시한 도면이다.

도 11은 본 발명의 객체-지향 구현에 따라 구성된 데이터베이스 및 트랜잭션 인터페이스들을 도시한 도면이다.

도 12는 본 발명의 객체-지향 구현에 따라 구성된 도큐먼트 및 엘리먼트 인터페이스들을 도시한 도면이다.

도 13은 본 발명의 객체-지향 구현에 따라 구성된 엘리먼트 통신 및 동기 인터페이스들을 도시한 도면이다.

도 14는 집합 매니저 API들로부터 집합 및 스토리지 매니저들의 주요 내부 부분들에 이르는 주 제어 경로들을 도시한 도면이다.

도 15는 본 발명의 객체-지향 구현에 따라 구성된 집합 매니저 인터페이스들을 도시한 도면이다.

도 1은 개시된 도큐먼트 관리 시스템이 구현될 수 있는 등록 상표 IBM THINKPAD 600과 같은 예시적인 클라이언트 컴퓨터(100)의 시스템 구조를 도시하고 있다. 도 1의 예시적인 컴퓨터 시스템은 단지 설명을 위한 목적으로 논의되는 것이 지 본 발명을 제한하려는 의도는 아니다. 다음의 설명은 특정한 컴퓨터 시스템들을 설명할 때 일반적으로 사용되는 용어들을 사용하지만, 설명되는 개념은 도 1에 도시된 것과 다른 구조를 갖는 시스템을 포함한 다른 컴퓨터 시스템들 또는 전통적으로 컴퓨터로서 인식되지 않는 게임 콘솔 또는 케이블 TV 셋탑박스와 같이 그 내부에 컴퓨터를 갖는 장치에 동일하게 적용된다.

클라이언트 컴퓨터(100)는 종래의 마이크로프로세서를 포함할 수 있는 중앙 처리 장치(CPU)(105), 정보의 일시적인 저장을 위한 랜덤 억세스 메모리(RAM)(110), 및 정보의 영구적인 저장을 위한 판독 전용 메모리(ROM)를 포함한다. 메모리 제어기(120)는 시스템 RAM(110)을 제어하기 위해 제공된다. 버스 제어기(125)는 버스(130)를 제어하기 위해 제공되고, 인터럽트 제어기(135)는 다른 시스템 컴포넌트들로부터의 다양한 인터럽트 신호들을 수신 및 처리하기 위해 사용된다.

대용량 스토리지가 디스켓(142), CD-ROM(147), 또는 하드디스크(152)에 의해 제공될 수 있다. 디스켓(142) 및 CD-ROM(147)과 같은 이동 가능한 매체를 통해 데이터 및 소프트웨어를 클라이언트 컴퓨터(100)와 주고 받을 수 있다. 디스켓(142)은 제어기(140)에 의해 버스(130)에 연결된 디스크 드라이브(141)로 삽입될 수 있다. 유사하게, CD-ROM(147)은 제어기(145)에 의해 버스(130)에 연결된 CD-ROM 드라이브(146)에 삽입될 수 있다. 최종적으로, 하드디스크(152)는 제어기(150)에 의해 버스(130)에 연결되는 고정 디스크 드라이브(151)의 일부이다.

클라이언트 컴퓨터(100)로의 사용자 입력은 다수의 장치에 의해 제공될 수 있다. 예를 들어, 키보드(156) 및 마우스(157)는 키보드 및 마우스 제어기(155)에 의해 버스(130)에 연결될 수 있다. 마이크로폰 및 스피커로서 동작할 수 있는 오디오 트랜스듀서(196)는 오디오 제어기(197)에 의해 버스(130)에 연결된다. 본 기술 분야에 숙련된 자에게는 펜 및/또는 태블릿과 음성 입력을 위한 마이크로폰과 같은 다른 입력 장치들이 버스(130) 및 적절한 제어기를 통해 클라이언트 컴퓨터(100)에 연결될 수 있다는 것은 명백하다. DMA 제어기(160)는 시스템 RAM(110)에 대한 직접 메모리 억세스를 수행하기 위해 제공된다. 비주얼 디스플레이는 비디오 디스플레이(170)를 제어하는 비디오 제어기(165)에 의해 이루어진다.

또한, 클라이언트 컴퓨터(100)는 클라이언트 컴퓨터(100)가 버스(191)를 통해 네트워크(195)에 상호 연결되도록 하는 네트워크 어댑터(190)를 포함한다. 근거리 통신망(LAN), 원거리 통신망(WAN), 또는 인터넷일 수 있는 이 네트워크(195)는 다수의 네트워크 장치들을 상호 연결시키는 범용 통신 라인을 사용할 수 있다.

클라이언트 컴퓨터(100)는 일반적으로 등록 상표 WINDOWS NT과 같은 운영 체제 소프트웨어(Microsoft Corp. Redmond, WA로부터 이용 가능함)에 의해 제어되고 조정된다. 다른 컴퓨터 시스템 제어 기능들 중에서, 운영 체제는 시스템 자원의 할당을 제어하고 프로세싱 스케줄링, 메모리 관리, 네트워킹 및 I/O 서비스들과 같은 태스크들을 수행한다.

도 2에 보다 상세히 도시된 바와 같이, 스토리지 매니저(206)는 RAM(200) [도 1의 RAM(110)과 동일] 내에 있으며 XML 도큐먼트들(228, 230)을 사용하는 어플리케이션 프로그램(202)과 도큐먼트들(228, 230)이 저장되는 영구적 스토리지(208) 사이의 인터페이스를 제공한다. 어플리케이션(202)은 객체들을 저장하는 데 사용되는 영구 스토리지(208)의 형태에 관계없이 일관된 어플리케이션 프로그래밍 인터페이스(204)에 의해 스토리지 매니저(206)와 상호 작용할 수 있다. 내부적으로, 스토리지 매니저(206)는 각각 객체들(212 내지 216 및 220 내지 224)의 계층적인 시리즈로서 각각의 도큐먼트(210, 218)를 표현한다. 스토리지 매니저(206)는 디렉토리 기반 파일 서비스들, 객체 저장 및 관계형 파일 시스템과 같은 다양한 파일 시스템을 사용하여 화살표 226에 의해 개략적으로 표시된 바와 같이 영구적 스토리지(208) 내에 도큐먼트들(210 및 218)을 저장할 수 있다.

본 발명의 시스템은 종래의 XML 파일들과 함께 동작한다. 완전한 XML 파일은 통상적으로 특정 마크업 태그들에 의해 정의되는 3개의 컴포넌트들로 구성된다. 첫 번째 2개의 컴포넌트는 선택 사항이고, 최종 컴포넌트는 필요한데, 이 컴포넌트들은 다음과 같이 정의된다.

1. 사용되는 XML의 버전, 엔코딩된 방식, 및 다른 파일들을 참조하는 지 여부를 식별하는 XML 프로세싱 스테이트먼트(processing statement). 이 스테이트먼트는 다음과 같은 형태를 취한다.

<?xml version="1.0"encoding="UTF-8"standalone="yes"?>

2. 파일 내에 존재하는 엘리먼트들 및 그 관계를 정의하는 도큐먼트 타입 정의(DTD). DTD는 타입을 기술하는 정식 마크업 태그 선언들 및 내부 서브셋 내의 (꺾쇠괄호 사이의) 파일의 마크업 태그의 콘텐츠를 포함하거나 관련 마크업 선언(외부 서브셋)을 포함하는 파일을 참조한다. 이러한 선언은 다음과 같은 형태를 갖는다.

<!DOCTYPE ApplSYSTEM"app.dat">

3. 루트 엘리먼트(그 엘리먼트 형태명은 도큐먼트 타입 선언 내의 도큐먼트 타입명과 일치해야 한다)로 구성된 태그된 도큐먼트 인스턴스(tagged document instance). 모든 다른 마크업 엘리먼트들은 루트 엘리먼트 내에 포함된다.

3개의 모든 컴포넌트들이 존재하고, 도큐먼트 인스턴스가 DTD 내에 정의된 도큐먼트 모델과 일치한다면, 도큐먼트는 "유효(valid)"인 것으로 언급된다. 최종 컴포넌트만이 존재하고, 정식 도큐먼트 모델이 존재하지 않지만, 각각의 엘리먼트는 그 부모 엘리먼트(parent element) 내에 적절하게 포함되어 있고, 각각의 속성은 값 인디케이터(=) 및 인용 부호 열이 후속하는 속성명으로서 특정된다면, 도큐먼트 인스턴스는 "웰 폼(well-formed)"된 것으로 언급된다. 본 발명의 시스템은 웰 폼 XML 도큐먼트를 생성 및 동작할 수 있다.

스토리지 매니저(206) 내에, XML 도큐먼트들은 종래의 XML 도큐먼트들로부터의 표현을 구별하기 위해 "그루브 도큐먼트(Groove Document)" 명으로 집합적으로 불리는 데이터 스토리지 파티션들에 의해 표현된다. 각각의 그루브 도큐먼트는 도큐먼트를 형성하는 다양한 엘리먼트들 간의 관계를 정규적으로 식별하는 DTD에 의해 기술될 수 있다. 이러한 DTD들은 표준 XML 포맷을 따른다. 또한, 각각의 그룹 도큐먼트는 도큐먼트 바디(body) 내에서 엘리먼트와 속성의 패턴을 기술하는 정의, 또는 스키마를 구비한다. 그러므로, 그루브 스키마 도큐먼트를 XML 데이터 도큐먼트와 연관시키기 위해, 스키마에 대한 URI 레퍼런스를 포함하는 특정 XML 프로세싱 명령이 데이터 도큐먼트 내에 삽입된다. 이러한 프로세싱 명령은 다음과 같은 형태를 갖는다.

<?schema URI="groovedocument:///GrooveXSS/$PersistRoot/sample.xml"?>

몇몇의 엘리먼트들은 콘텐츠를 가지거나 필요로 하지 않고 임의의 프로세스가 발생하는 곳을 표시하는 플레이스홀더로서 동작한다. 태그의 특수 형태가 임의의 콘텐츠를 갖지 않는 비어 있는 엘리먼트들을 지시하는 XML 내에 사용되며, 따라서, 종료 태그를 갖지 않는다. 예를 들어, <ThumbnailBox> 엘리먼트는 텍스트 라인 내에 삽입된 이미지에 대한 플레이스홀더로서 작용하며 DTD 내에 다음과 같은 선언을 갖는 대체로 비어 있는 엘리먼트이다.

<!ELEMENT ThumbnailBox EMPTY>

엘리먼트들은 다양한 형태들을 가질 수 있거나 함께 링크될 필요가 있어, 이들은 적용되는 특정들을 특정하는 적절한 속성들이 제공될 수 있다. 이러한 속성들이 목록에 특정되어 있다. 예를 들어, 이는 <ThumbnailBox> 엘리먼트는 로케이션 및 크기 속성들을 포함하는 것이 결정될 수 있다. 이러한 속성을 위한 적절한 속성 리스트 선언은 다음과 같다.

<!ATTLIST ThumbnailBox

Location ENTITY #REQUIRED

Size CDATA #IMPLIED

>

이는 <ThumbnailBox> 엘리먼트가 요구되는 로케이션 실체를 포함하며 크기 속성을 포함할 수 있다는 것을 컴퓨터에게 전한다. 키워드 #IMPLIED는 <ThumbnailBox> 엘리먼트의 몇몇의 인스턴스들 내의 속성을 생략하는 것이 가능하다는 것을 나타낸다.

또한, XML은 몇몇의 컴파일러에서 사용되는 #DEFINE 스테이트먼트들과 유사한 커스텀 정의 스테이트먼트들을 허용한다. 일반적으로 사용되는 정의들은 DTD 내에 "실체들"로서 선언될 수 있다. 전형적인 실체 정의는 다음과 같은 형태를 취한다.

<!ENTITY BinDoc3487 SYSTEM"./3487.gif" NDATA>

이는 이진 도큐먼트 "BinDoc3487"에 대한 파일 로케이션을 정의한다. 이러한 선언이 DTD 내에 이루어지면, 사용자들은 전체 값 대신에 레퍼런스를 사용할 수 있다. 예를 들어, 이미 기술된 <ThumbnailBox> 엘리먼트는 <ThumbnailBox Location=BinDoc3487 Size="Autosize"/>로서 특정될 수 있다. 이러한 기술을 사용하는 장점은 정의된 값이 변화하면 후에 실체 레퍼런스가 현재{의} 선언의 콘텐츠를 자동적으로 사용함에 따라 DTD 내의 실체(entity) 선언만 갱신하면 되는 데 있다.

저장 매니저 내에, 각각의 도큐먼트 부분은 RFC 2396에서 특정된 바와 같은 표준 포맷과 일치하는 유니폼 리소스 식별자(URI)에 의해 식별된다. URI들은 절대적 또는 상대적일 수 있지만, 상대적 URI들은 절대적 기준인 URI의 컨텍스트 내에만 사용되어야 한다. 도큐먼트가 영구적 스토리지 내에 저장될 때, 그 부분들은 사용 시 특정한 파일 시스템에 의해 할당 및 관리되는 상이한 STORAGEURI에 의해 식별될 수 있다.

본 발명의 원리에 따르면, 각각의 도큐먼트 부분 내에서, 스토리지 매니저 내의 내부 메모리는 객체들의 집합에 의해 표현된다. 예를 들어, XML 도큐먼트 내의 개별적인 엘리먼트들은 스토리지 매니저 내에 엘리먼트 객체들로서 표현된다. 이는 도 3에 도시된 구조를 이룬다. 도 3에서, 예시적인 XML 도큐먼트(300)는 스토리지 매니저(302) 내의 객체들의 집합으로서 표현된다. 특히, XML 도큐먼트(300)는 상술한 바와 같이 XML 버전, 엔코딩, 및 파일 레퍼런스를 식별하는 종래의 XML 프로세싱 스테이트먼트(304)를 포함한다. 또한, 도큐먼트(300)는 도큐먼트(300)와 연관된 스토리지 매니저(302) 내의 스키마 도큐먼트(320)를 식별하는 XML 프로세싱 스테이트먼트(306)를 포함한다. 또한, 예시적인 XML 도큐먼트는 몇몇의 텍스트(318)를 포함하는 엘리먼트 A(308)를 포함하는 일련의 계층적인 엘리먼트들을 포함하는데, 여기서 엘리먼트 A는 그것과 연관된 텍스트를 가지지 않는 엘리먼트 B(310)를 포함한다. 또한, 엘리먼트 B는 차례로 2개의 엘리먼트를 포함하는 엘리먼트 C(312)를 포함한다. 특히, 엘리먼트 C는 속성(ID, "foo" 값을 가짐) 및 엘리먼트 E(316)를 갖는 엘리먼트 D(314)를 포함한다.

스토리지 매니저(302)에서 엘리먼트들, 엘리먼트 A - 엘리먼트 E는 계층적으로 배열된 엘리먼트 객체들로서 표현된다. 특히, 엘리먼트 A는 엘리먼트 A 객체(322)에 의해 표현된다. 각각의 엘리먼트 객체는 대응하는 XML 엘리먼트 내에 포함된 텍스트 및 속성들을 포함한다. 그러므로, 엘리먼트 객체(322)는 텍스트(318)를 포함한다. 유사하게, 엘리먼트 B(310)는 엘리먼트 객체(324)에 의해 표현되며 엘리먼트들(엘리먼트 C, 엘리먼트 D, 및 엘리먼트 E)은 각각 객체들(326, 328, 및 330)에 의해 표현된다. 엘리먼트 D를 표현하는 엘리먼트 객체(328)는 또한 대응하는 엘리먼트 내에 포함된 속성 ID를 포함한다. 각각의 엘리 먼트 객체는 엘리먼트 객체들을 계층으로 배열하도록 순서대로 (객체들 사이에 화살표로 표시되는) 데이터베이스 포인터들에 의해 그 자식 엘리먼트 객체들을 참조한다. 또한, 엘리먼트 객체(328) 내의 ID 속성을 인덱싱하는 인덱스(332)와 같은 속성 인덱스들이 존재할 수 있다.

객체 집합에 의한 XML 도큐먼트(300)의 표현은 스토리지 매니저(302)가 다음에서 보다 상세히 논의되는 일관된 인터페이스로 도큐먼트(300)의 내부 표현을 조작하도록 해준다. 또한 스토리지 매니저(302)는 다음에서 보다 상세히 논의되는 집합 매니저를 통해 이용 가능한 집합 서비스와 같은 종래의 XML 도큐먼트들에서 이용 가능하지 않은 특징들을 제공할 수 있다.

상술한 바와 같이, XML 데이터를 포함하는 그루브 도큐먼트들은 도큐먼트의 바디 내의 엘리먼트들 및 속성들의 패턴을 기술하는 정의, 또는 스키마 도큐먼트를 가질 수 있다. 스키마 도큐먼트는 URI에 의해 식별되는 개별적인 XML 도큐먼트 내에 저장된다. 스키마 도큐먼트는 다음과 같이 표현되는 소위 메타 스키마라 불리는 표준 XML DTD 정의를 갖는다.

스키마 내의 각각의 엘리먼트들은 도큐먼트의 프로세싱 동안에 스토리지 매니저에 의해 사용되는 정보를 정의한다. "Registry" 섹션은 XML 엘리먼트 태그들을 WindowsProgID들로 맵핑하는 2열 테이블의 XML 표현을 형성한다. [Microsoft Corporation에 의해 개발된 공통 객체 모델(COM)에서, ProgID는 COM 시스템 내에서 "바운드"되거나 프로그램 코드의 섹션과 연관되는 객체를 위한 텍스트명이다. 주어진 ProgID와 라이브러리 내에 저장된 프로그램 코드 사이의 맵핑은 등록 상표 Windows registry와 같은 정의 영역 내에 특정된다.]

이러한 배열은 XML 도큐먼트(400) 및 그 관련 스키마 도큐먼트(402)를 도시한 도 4A에 도시되어 있다. 이 양 도큐먼트들은 스토리지 매니저(406) 내에 존재하며 실제로 도 3에 도시된 바와 같이 객체들에 의해 표현된다. 그러나, 도 4에서, 도큐먼트들은 명확하게 하기 위해 종래의 XML 포맷으로 표현되었다. 도 4는 Microsoft Corporation, Redmond, Washington에 의해 개발된 공통 객체 모델(COM)에 따라 생성된 객체들을 사용한 등록 상표 Windows 환경에서 동작하는 스토리지 매니저를 도시하고 있으며, 동일한 원리가 다른 운영 체제 환경에 적용된다.

XML 도큐먼트(400)는 XML 버전, 엔코딩 및 파일 레퍼런스들을 식별하는 통상적인 XML 프로세싱 스테이트먼트(414)를 포함한다. 스키마 XML 프로세싱 스테이트먼트(416)는 {스키마 도큐먼트가} 도큐먼트(400)와 연관되고 네임 스테이트먼트(426)에 의해 정의된 네임 "urn:groove.net:sample.xml"을 갖는 스키마 도큐먼트(402)를 참조한다. 또한, 스키마 SML 프로세싱 스테이트먼트(416)는 네임 "doc.xml" 및 "urn:groove.net"로서 정의된 "g" XML 네임스페이스를 정의하는 루트 엘리먼트(418)를 포함한다.

도큐먼트(400)는 태그 "urn:groove.net:AAA"에 의해 정의된 엘리먼트(420), 태그 "urn:groove.net:BBB"에 의해 정의된 엘리먼트(422), 및 태그 "urn:groove.net: NoCode"에 의해 정의된 엘리먼트(424)를 포함하는 3개의 다른 엘리먼트들을 갖는다. 엘리먼트(424)는 스키마 도큐먼트(402) 내에서 맵핑하는 대응하는 바운드 코드 및 대응하는 tag-to-ProgID 맵핑을 갖지 않는 간단한 엘리먼트이다.

태그(428)에 의해 정의되는 "registry" 섹션 내에서, 스키마 도큐먼트(402)는 정의된 2개의 element-to-COM ProgID 맵핑들을 갖는다. 한 맵핑은 태그 "urn:groove.net:AAA"를 갖는 엘리먼트를 위해 정의되고 다른 하나는 태그 "urn: groove.net:BBB"를 갖는 엘리먼트를 위해 정의된다. 바운드 코드는 클라이언트 어플리케이션(404)이 방법 "OpenBoundCode()"를 호출할 때 억세스된다. 이러한 호출을 위한 구문은 다음의 표 15에 제공되어 있으며 포함된 단계들은 도 4B에 도시되어 있다. 엘리먼트(424)와 같은 간단한 엘리먼트 상의 OpenBoundCode() 메소드(method)를 호출하는 것은 예외를 발생시킨다. 바운드 코드를 검색하는 프로세스는 단계 434에서 시작하여 OpenBoundCode()가 호출되는 단계 436으로 진행한다. 엘리먼트 태그 "urn:groove.net:AAA"를 갖는 엘리먼트 상의 OpenBoundCode() 메소드를 호출하는 것은 스토리지 매니저(406)가 단계 438에서와 같은 엘리먼트 태그를 갖는 스키마 도큐먼트(602) 내의 레지스트리 엘리먼트(428)를 참고하도록 한다. 섹션 430으로부터, 스토리지 매니저는 단계 440에 표시된 것처럼 ProgID "Groove.Command"를 검색한다. 단계 442에서, 스토리지 매니저는 이 ProgID를 갖는 객체를 생성하도록 지시 받았을 때 COM 매니저(408)를 호출한다. 종래의, 널리 공지된 방식으로, 단계 444에서, COM 매니저는 Windows Registry(410) 내의 키를 사용하여 ProgID를 CSLID로 번역한다. 단계 446에서, COM 매니저는 CSLID를 사용하여 그 객체에 대한 코드를 갖는 코드 데이터베이스(412) 내의 동적으로 로딩 가능한 라이브러리(DLL) 파일을 탐색한다. 최종적으로, 단계 448에서, COM 매니저는 객체를 생성하고 차례로 포인터를 클라이언트 어플리케이션(404)으로 리턴하는 스토리지 매니저(406)로 객체에 대한 인터페이스 포인터를 리턴한다. 다음에, 루틴은 단계 450에서 종료한다. 클라이언트 어플리케이션(404)은 연관된 엘리먼트 내의 속성들 및 콘텐츠를 사용하는 코드 내에서 메소드들을 호출하도록 포인터를 사용할 수 있다. 다음에, 엘리먼트는 임의의 다른 COM 객체와 같이 동작한다. OpenBoundCode() 메소드가 태그 "urn:groove.net:BBB"를 갖는 엘리먼트들 상에서 호출된다면 유사한 프로세스가 발생한다.

"AttrGroup" 섹션은 속성을 위한 비-XML 특성을 정의한다. 속성의 데이터 타입은 텍스트가 아닌 몇몇의 다른 형태로서 정의될 수 있으며 속성은 그것을 포함하는 엘리먼트들의 고속 검색을 용이하게 하도록 인덱싱될 수 있다.

"ElementDecl" 섹션은 DTD <!ELEMENT> 선언과 유사한 엘리먼트 정의의 형태를 제공하지만, 확장된 속성 특성들 및 비제한 엘리먼트 레퍼런스들의 정의를 가능하게 한다.

다음의 예는 이전에 기술된 "텔레스페이스"를 정의하는 XML 도큐먼트를 위한 스키마 도큐먼트의 샘플 부분을 나타내고 있다.

본 예에서는, Tag to ProgID 맵핑 테이블 내에 2개의 실체들이 존재한다. 첫 번째는 (XML 네임스페이스 확장을 사용한 "ㅕ구:groove.net.schema.1:Command"인) 태그 "g:Command"를 ProgID "Groove.Command"로 맵핑한다. 속성을 정의하는 섹션에서, "ID" 속성이 인덱싱되고, NKey 속성의 데이터 형태는 이진 등이다.

이러한 스키마 데이터는 엘리먼트 객체들에 의해 표현되며 다음에서 보다 상세히 설명되는 바와 같이 도큐먼트들을 조작하기 위해 사용되는 동일한 스토리지 매니저 엘리먼트 및 속성 인터페이스 메소드들에 의해 억세스 및 조작될 수 있다. 특히, 도큐먼트를 기술하는 정보는 도큐먼트 콘텐츠를 조작하기 위해 사용되는 동일한 인터페이스들을 사용하여 조작될 수 있다.

본 발명의 다른 특징에 따르면, 서브-도큐먼트들은 프라이머리 도큐먼트와 연관될 수 있다. 임의의 도큐먼트는 주어진 도큐먼트의 서브-도큐먼트일 수 있다. 도큐먼트가 다른 도큐먼트에 대한 서브-도큐먼트 레퍼런스를 포함한다면, 레퍼런스된 도큐먼트는 서브-도큐먼트이다. 2개의 도큐먼트들이 서로에 대한 서브-도큐먼트 레퍼런스들을 가진다면, 각각의 도큐먼트는 다른 도큐먼트의 서브-도큐먼트이다. 각각의 서브-도큐먼트는 http://www.w3.org/TR/xlink/에 보다 상세히 설명된 종래의 XML XLink 언어로 프라이머리 도큐먼트로부터 레퍼런스된다. 링크들은 또한 모든 텍스트 XML 도큐먼트와 이진 서브-도큐먼트 사이의 관계를 설정한다. 이진 도큐먼트들은 임의의 종류의 서브-도큐먼트에 대한 링크들을 갖지 않는다. 링크가 도큐먼트 프래그먼트에 대한 것이라면, 서브도큐먼트 관계는 프래그먼트를 포함하는 도큐먼트에 대해 설정된다. 도큐먼트들과 서브-도큐먼트들의 관계는 도 5에 도시되어 있다.

예를 들어, 메인 도큐먼트(500)는 화살표 510으로 표시된 도큐먼트(504)에 대한 링크, 및 화살표 508로 표시된 이진 도큐먼트(506)에 대한 링크를 포함하는 링크들(502)을 가진다. 도큐먼트들(504 및 506)은 따라서 도큐먼트(500)의 서브-도큐먼트들이다. 도큐먼트(504)는 차례로 화살표 514에 의해 표시되는 콘텐츠(518)를 갖는 도큐먼트(516)로의 링크를 포함하는 링크들(512)을 가진다. 도큐먼트(516)는 도큐먼트(500)의 서브-도큐먼트이다. 도큐먼트(506)는 이진 콘텐츠(520)를 포함하므로, 서브-도큐먼트들로의 링크들을 가질 수 없다.

서브-도큐먼트 링크들은 간단히 링크들에 대한 표준 정의를 따른다. 링크의 예시적인 엘리먼트 정의는 다음과 같다.

또한, "simple"값을 갖는 xml:link 속성, 및 href 속성을 갖는 XML 링크를 도큐먼트에 추가함으로써 상기와 같은 정의 없이 서브-도큐먼트 관계를 설정하는 것이 가능하다. 이러한 링크는 href 속성 내의 URI 값에 의해 식별되는 도큐먼트에 서브-도큐먼트 관계를 설정할 것이다.

도큐먼트로부터 그 서브-도큐먼트들로의 관계들이 주어지면, 임의의 세트의 도큐먼트들 및 서브-도큐먼트들의 카피를 작성하는 것이 가능하다. 단일 스토리지 서비스에서, 이러한 카피를 직접 수행하는 것이 가능해질 수 있다. 스토리지 서비스들을 교차시키거나 다중 도큐먼트들을 다른 머신으로 전송하기 위해서는, 도큐먼트들의 전체 계층은 일련화된 형태로 "기술 가능"하여야 한다. 본 발명의 스토리지 매니저는 다중 도큐먼트들을 ftp://ftp.isi.edu/in-notes/rfc2557.txt/에 보다 상세히 설명된 HTML(MHTML)과 같은 Aggregate 도큐먼트들의 MIME Encapsulation의 명세와 일치하는 텍스트 표현으로 일련화한다.

다음의 데이터 스트림 프래그먼트는 MHTML 문자열에서 보여지듯이 도큐먼트 및 레퍼런스된 서브-도큐먼트의 예이다.{도큐먼트 및 레퍼런스된 서브-도큐먼트의 예인데 이는 이들이 MHTML 문자 열에 나타나기 때문이다.} 본 예에서, "SP"는 하나의 스페이스가 존재한다는 것을 의미하며 "CRLF"는 캐리지 리턴-라인 피드(carriage return line feed) ASCII 문자 쌍을 표현한다. 모든 다른 문자들은 그대로 전송된다. MIME 버전 헤더는 통상적인 MIME 버전을 가지며 그루브 프로토콜 버전은 RFC822 코멘트에 있다. 이 코멘트는 정수가 뒤따르는 단어 "그루브"이다. 바운더리 세퍼레이터 스트링은 유일하여, MIME 및 각각의 본체부를 파싱한 시스템이 올바르게 동작할 것이다. 일련화된 XML 텍스트가 UTF-8 포맷에 도시되어 있지만, 또한 WBXML 포맷으로 전송될 수 있다. XML 도큐먼트는 버전 및 문자 엔코딩을 포함하는 XML 프리픽스를 갖는다. 이진 도큐먼트는 베이스(64)에서 엔코딩된다.

도큐먼트 에디터들 또는 인터넷 브라우저들과 같은 대부분의 XML 프로세서들과 달리, 스토리지 매니저는 동시에 도큐먼트 작업들을 할 수 있다. 도큐먼트들은 동시에 탐색될 수 있고, 엘리먼트들은 동시에 생성, 삭제, 업데이트, 또는 이동될 수 있다. 엘리먼트 계층들의 카피들은 한 도큐먼트로부터 다른 도큐먼트로 이동될 수 있다. 대부분의 XML 프로세서들에서, 도큐먼트에 대한 모든 업데이트들은 대개 단일 컴퓨터 상의 단일 프로세스 내의 단일 쓰레드를 제어하는 단일 유저에 의해 구동된다.

스토리지 매니저는 다중 프로세스들 내의 다중 쓰레드들을 사용하여 동일한 도큐먼트를 업데이트하는 다수의 사용자들 사이의 XML 도큐먼트 통합성을 유지한다. 바람직한 실시예에서, 모든 업데이트들은 단일 컴퓨터 상에서 발생하지만, 다른 상이한 종래의 인터-프로세서 통신 메카니즘들을 사용하여, 다른 동작 실시예들도 가능하다. 도 6은 스토리지 매니저의 기본적인 구조를 도시하고 있으며 크로스-프로세스 통신 이슈들로부터 어플리케이션 프로그램들을 어떻게 분리시키는 지를 도시하고 있다. 예를 들어, 2개의 개별적인 프로세스들(600 및 602)은 동일한 컴퓨터 또는 상이한 컴퓨터들에서 동시에 동작할 수 있다. 프로세스(600)은 후술하는 바와 같이 "홈(home)" 프로세스이며, 프로세스(602)는 프로세스 N으로 지시되는 다른 프로세스이다. 프로세스(600) 내에서, 멀티 쓰레드 클라이언트 어플리케이션 프로그램(606)이 동작하며, 프로세스 (602) 내에서, 멀티 쓰레드 클라이언트 어플리케이션 프로그램(616)이 동작한다.

각각의 어플리케이션 프로그램(606 및 616)은 각각 605 및 615로 지시된 스토리지 매니저와 인터페이스한다. 프로세스 (600)에서, 스토리지 매니저는 스토리지 매니저를 제어 및 인터페이스하는 어플리케이션 프로그램(606)에 의해 사용되는 스토리지 매니저 인터페이스층(608)을 포함한다. 이는 어플리케이션에 의해 실제로 조작되는 데이터베이스, 도큐먼트, 엘리먼트, 및 스키마 객체들을 포함한다. 이 층에 의해 익스포트(export)되는 API는 다음에서 보다 상세히 논의된다. 스토리지 매니저(605)는 또한 가상 분산 객체(DVO) 데이터베이스 메소드들(610), 및 기초 데이터 타입들을 위한 DVO 메소드들(612), DVO 공통 시스템 메소드들(609), 및 분산 공유 메모리(614)를 포함한다. 유사하게, 프로세스 602에서 동작하는 스토리지 매니저는 트랜잭션층(618), DVO 데이터베이스 방법(620), 기초 데이터 타입들을 위한 DVO 방법들(622), DVO 공통 시스템 방법들(617), 및 분산 공유 메모리(624)를 포함한다.

2개의 프로세스들(600 및 602)은 종래의 메시지 패싱 프로토콜 즉, 인터-프로세스 통신(IPC) 시스템(604)을 통해 통신한다. 단일 컴퓨터에서 실행되는 프로세스들에 있어서, 이러한 시스템은 시스템은 등록 상표 Windows 운영 체제에서 공유 메모리 버퍼들에 의해 구현될 수 있다. 프로세스들이 개별적인 컴퓨터들에서 실행된다면, TCP/IP와 같은 다른 메시지 패싱 프로토콜이 사용될 수 있다. 다른 종래의 메시징 또는 통신 시스템들 또한 본 발명의 동작을 수정하지 않으면서 사용될 수 있다. 그러나, 도 6에 도시된 바와 같이, 어플리케이션 프로그램들(606 및 616)은 메시지 패싱 시스템(604)과 직접 상호 작용하지 않는다. 대신에, 어플리케이션 프로그램들(606 및 616)은 각각 스토리지 매니저들(605 및 615)과 상호 작용하며, 스토리지 매니저들(605 및 615)은 DSM 시스템들(614 및 624)이 그 일부를 이루는 분산 공유 메모리(DSM) 시스템을 통해 메시지 패싱 시스템(604)과 상호 작용한다.

다수의 널리 공지된 DSM 시스템들이 존재하며 본 발명과 함께 사용하기에 적합하다. 바람직한 실시예에 따르면, 스토리니 매니저와 함께 사용되는 DSM 시스템은 소위 C Region Library(CRL) 시스템이라 불린다. 이 CRL 시스템은 메시지 패싱 멀티 컴퓨터 및 분산 시스템 상에서 사용하기 위한 소프트웨어로 된(all-software) 분산 공유 메모리 시스템이다. CRL 시스템 및 이 시스템을 구현하기 위한 코드는 제목 "CRL: High-Performance All-Software Distributed Memory System", K.L. Johnson, M.F. Kaashoek 및 D.A. Wallach, Proceedings of the Fifteenth Symposium on Operating Systems Principles, ACM, December 1995; 및 "CRL version 1.0 User Documentation", K.L. Johnson, J.Adler 및 S.K.Gupta, MIT Laboratory for Computer Science, Cambridge, MA 02139, August 1995 기사에 보다 상세히 기술되어 있다. 두 기사 모두 웹 주소 http://www.pdos.lcs.mit.edu/crl/에서 이용 가능하다.

스토리지 매니저와 같은 CRL의 상부 상에 구축된 패러렐 어플리케이션들은 메모리 "영역들"을 통해 데이터를 공유한다. 각각의 영역은 임의의 크기의 연속적인 메모리 영역이다. 공유된 메모리 영역들은 DSM 시스템의 다양한 기능들에 의해 생성, 다른 프로세스들에 맵핑, 언맵핑, 및 파괴된다. 본 발명에 사용된 DSM 시스템은 CRL DSM 시스템에 사용되는 함수들의 수퍼셋(super-set)을 제공한다. 메모리 영역들의 사용자들은 그들이 영역으로부터 판독하거나 영역에 기입할 필요가 있을 때 선언에 의해 그들의 DSM으로의 접근을 동기화하고, 이후 영역의 사용 후에 판독이나 기입의 종료를 선언한다. 기입 동작의 효과는 다른 프로세스들이 해당 영역을 필요로 한다는 요구를 선언할 때까지 영역을 공유하는 다른 프로세스들로 전달되지 않는다. 기본 공유 메모리 및 동기 동작들에 추가하여, DSM은 오류 처리 및 트랜잭션(transaction)에서의 신뢰성을 제공한다. 본 발명의 DSM에 대한 전체 인터페이스는 표 1에 나타나 있다.

DSM 방법

설명

AddNotification(DSMRgn*i_pRgn,const IgrooveManualResetEvent*i_pEvent); Close(); Create(UINT4i_Size, INT4 i_CallbackParam, IncAddress i_InitialOwner, DsMRId&io)Rid, DSMRgn*&o_pRgn, void*&o_pData); AddDatabase(UINT2i_DatabasNumber); DatabaseFlushNotify(UINT2 i_DatabaseNumber, TimeMillis i_StartTime); Destroy(DSMRId&i_RId); EndRead(DSMRRgn*i_pRgn; EndWrite(DSMRRgn*i_pRgn; Flush(DSMRgn*i_pRgn); GetSize(DSMRgn*i_pRgn);

영역 변화의 데이터로 시그널링될 로컬 이벤트 추가. DSM 폐쇄. 이 클라이언트에서 맵핑된 영역들이 존재하지 않아야 함. 새로운 영역 형성. 또한 새로운 영역을 자동적으로 맵핑 및 크기가 0이 아닌 경우 StartWrite 개시. 크기는 새로운 영역 내의 데이터의 초기 크기임. RId는 새로운 영역 식별자임. pRgn은 크기가 0이 아닌 경우 새로운 영역임. 새로운 데이터베이스를 영역 맵핑 테이블들에 추가. 사용되지 않은 영역 리소스를 클린업. 기존 영역을 완전히 파괴. RId는 파괴되는 영역의 유효 식별자임. 영역의 데이터 상의 판독 동작을 종료. pRgn은 유효 영역임. 영역의 데이터상의 기입 동작을 종료. pRgn은 유효 영역임. 클라이언트의 로컬 캐쉬로부터 영역의 홈 클라이언트로의 영역 플러싱. pRgn은 유효 영역임. 주어진 유효 영역의 크기(바이트 수)를 리턴. pRgn은 유효 영역임.

DSM 방법

설명

Init(CBSTR i_BroadcastGroup, DSMRgnMapCallback*i_pCallback= NULL, void*i_pCallbackParam=NULL, BOOL*o_pMasterClient=NULL, UINT4 i_WaitTimeOut=1000,UINT4i_URCSize =1<<10,INCAddress*o_pAddress= NULL); Map(const DSMRld&i_RId,INT4 i_CallbackParam, BOOL i_InitialOwner); RemoveDatabase(UINT2 i_DatabaseNumber); RemoveNotification(DSMRgn*i_pRgn, const IgrooveManualResetEvent* i_pEvent); Resize(DSMRgn* i_pRgn, UINT4i_Size); GetRId(const DSMRgn*i_pRgn); SignalNotification(DSMRgn*i_pRgn); StartRead(DSMRgn*i_pRgn, INT4 i_CallbackParam, void*&o_pData); StartTransactionRead(DSMRgn*i_pRgn, INT4i_CallbackParam, void*&o_pData); StartTransactionWrite(DSMRgn*i_pRgn, INT4i_CallbackParam, void*&o_pData); StartWrite(DSMRgn*i_pRgn, INT4 i_CallbackParam, void*&o_pData); Unmap(DSMRgn*i_pRgn);

DSM 개시. BroadcastGroup은 DSM 클라이언트가 속하는 그룹 이름임. URCSize는 언맵핑 영역 캐시의 크기임. PAddress는 DSM 클라이언트의 인터-노드 통신 어드레스임. pMasterClient는 DSM 클라이언트가 Master(첫번째) 클라이언트인 지를 특정함. 영역을 이 클라이언트 메모리 공간으로 맵핑. RId는 맵핑되는 영역의 유효 식별자임. 영역 맵핑 테이블로부터 특정 데이터베이스를 제거. 영역 내의 데이터에 대한 변화 제거. (크기가 감소된 경우 버려질 수 있는) 원본 데이터를 유지하는 동안 주어진 유효 영역을 리사이즈. 크기는 새로운 크기임. 주어진 유효 영역에 대한 식별자를 리턴. pRgn은 유효 영역임. 통지가 발생한 신호를 세트. 영역의 데이터 상의 판독 동작을 개시. RgnStartRead(또는 RgnStartWrite)는 데이터가 판독되기 전에 호출되어야 함. pRgn은 유효 영역임. 영역의 데이터 상의 트랜잭션 기입 동작을 개시. RgnStartRead(또는 Rgn StartWrite)는 데이터가 판독될 수 있기 전에 호출되야 함. pRgn은 유효 영역임. 영역의 데이터 상의 트랜잭션 기입 동작을 개시. RgnStartWrite는 데이터가 변경될 수 있기 전에 호츨되어야 함. pRgn은 유효 영역임. 영역의 데이터 상의 기입 동작을 개시. RgnStartWrite는 데이터가 변경될 수 있기 전에 호출되어야 함. pRgn은 유효 영역임. 클라이언트 메모리 공간으로부터의 영역을 언맵핑. pRgn은 언맵핑된 유효 영역임.

각각의 스토리지 매니저(605 및 615)는 대응하는 프로세스(600, 602)의 어드레스 공간 내에 로케이트한 하나 이상의 DSM 영역들(도 6에서 도시 생략)을 사용하는 DSM 노드를 포함한다. 이러한 영역들은 도큐먼트들, 엘리먼트들, 및 스토리지 매니저에 의해 관리되는 XML 데이터의 스키마를 표현하도록 사용될 수 있는 DVO 객체들 및 클래스들을 포함한다. 대게 엘리먼트들, 및 인덱스 섹션들인 도큐먼트들의 일부는 영역 내에 완전히 포함된다. DSM 시스템이 영역들을 공유하기 위한 개념적으로 단일한 노드 공간을 제공하지만, 특정 태스크들을 수행하도록 특정 노드 또는 프로세스를 선출하려는 요구를 발생시키는 이슈가 존재한다.

결과적으로, DSM 동기 프로토콜 내에서, 단일 노드는 각각의 영역에 대한 "홈 노드(home node)"로서 식별된다. 단일 컴퓨터 상에서 스토리지 매니저를 실행하는 다수의 프로세스들 중에서, 한 프로세스, 소위 "홈 프로세스"는 모든 디스크 I/O 동작들을 수행하는 프로세스이다. 프로세스들 간의 데이터 이동량을 감소시키기 위해, 홈 프로세스는 모든 영역들에 대한 홈 노드가 된다. 임의의 노드가 임의의 영역에 대한 홈일 수 있으며 임의의 프로세스가 디스크 I/O를 수행할 수 있는 다른 구현들이 가능하다. 그러나, 하나의 디스크 드라이브를 갖는 개인용 컴퓨터에 있어서, 디스크 I/O를 수행하는 다중 프로세스들을 가능하게 하는 것은 단일 디스크인 주요한 성능 병목을 완화시키지 않으면서 I/O 동기에 대한 요구를 발생시킨다.

DSM 동작에 따르면, 프로세스가 영역의 가장 최근의 카피를 갖는 경우, 영역에 판독 및 기입할 수 있다. 그렇지 않으면, 프로세스는 그 영역으로부터 판독 및 기입 이전에 홈 프로세스로부터 가장 최근의 카피를 요청해야 한다. 각각의 DSM 시스템(614, 624)은 DVM 시스템을 하부 트랜스포트 메카니즘으로부터 분리시키는 인터페이스층, 소위 인터모드 통신층(615, 625)을 통해 메시지 패싱 시스템(604)과 인터페이스한다. 이는 브로드캐스트 그룹에 메시지를 전송하고 대응하는 프로세스 및 홈 프로세스에 대한 어드레스들을 조작하는 방법을 포함한다.

본 발명의 스토리지 매니저는 XML 객체에 대한 기반으로서 공유 객체들을 사용한다. 다수의 시스템이 프로세스들 및 컴퓨터들에 걸쳐 객체들을 공유하기 위해 존재한다. 하나의 이러한 객체-공유 모델은 운영 체제에 의해 제공되는 공유 메모리 설비의 사용에 기초한다. 이러한 공유 메모리 모델의 가장 큰 결점들 중 하나는 다른 프로세스들의 통합성에 충격을 가하는 메모리 기입 오류들로 인한 비신뢰성이다. 예를 들어, 한 프로세스가 객체의 상태를 갱신하는 프로세스 내에 있고 그 프로세스가 알려진 양호한 상태로 객체를 세팅하기 전에 오류가 발생한다면, 그 외의 프로세스들은 객체를 무효 상태로 보거나 또는 그 동기 락을 해제하기 위해, 오류가 발생된 프로세스를 무한정 기다리는 것을 방지할 것이다. 또한, 공유 메모리 모델은 단단히 결합된 다중 컴퓨터 내의 공유 메모리의 지역 제한을 겪는다. 이는 네트워크를 통해 객체들을 공유하는 방법을 제공하지 않는다.

분산 객체 공유 및 원격 메소드 호출을 제공하는 다른 모델은 자바 또는 객체 관리 그룹의 CORBA 시스템에서의 분산 객체 관리 설비에 기초한다. 컴퓨터 네트워크를 통해 객체들을 공유하는 능력을 제공하였지만, 이러한 시스템의 클라이언트들은 객체가 로컬(local)인지 원격(remote)인지 알 필요가 있다. 객체는 로케이션 독립적이 아니다. 성능은 이러한 접근 방식의 다른 결점이다. 객체 상의 모든 동작은 객체 서버로 전송될 필요가 있는데, 이는 서버가 객체 상태의 카피만을 포함하여 그 데이터에 대한 동기 포인트로서의 역할을 하기 때문이다.

이러한 결점들을 극복하기 위해, 본 발명의 스토리지 매니저는 분산 가상 객체(DVO) 시스템을 사용하여 XML 객체 타입들이 구축된 프리미티브(primitive) 데이터 타입들을 제공한다. 또한, DVO 시스템은 데이터가 다수의 컴퓨터들 상에서 다수의 프로세스들 내에 있던지 아니면 실제로 단일 컴퓨터 노드 상에서 하나의 프로세스 내에만 존재하던지 간에, 모든 데이터가 단일 컴퓨터 노드 상에서 하나의 프로세스 내에 신뢰성 있게 포함되는 환영을 그 호출자에게 제공한다.

DVO 객체-공유 모델이 도 7에 도시되어 있다. 객체를 공유하는 모든 컴퓨터들 상의 모든 프로세스들은 동일한 메소드 코드를 갖는다. 예를 들어, 도 7에서 프로세스 700 및 프로세스 702는 동일한 객체의 카피들을 갖는다. 따라서, 프로세스들(700 및 702) 각각은 각각의 프로세스 어드레스 공간 내에 동일한 메소드 코드(704 및 706)의 카피를 갖는다. 객체에 대한 휘발성 데이터 상태는 DSM 영역들 내에 저장된다. 따라서, 프로세스 700 내의 객체 카피에 대한 객체 데이터(708)는 프로세스 700의 어드레스 공간 내의 영역(710) 내에 저장된다. 유사하게, 프로세스 702 내의 객체 카피에 대한 객체 데이터(712)는 프로세스 702의 어드레스 공간 내의 영역(714) 내에 저장된다. 객체 메소드는 화살표 716으로 표시된 바와 같이 영역들을 동기화시키는 DSM 동기화 함수들을 사용함으로써 객체의 데이터에 대한 그들의 억세스를 동기화시킨다. 이러한 방식으로, DVO 객체들은 로케이션 독립적이고, 오류가 단일 프로세스 내에 포함되어 있으며, 로컬 객체에 대한 다수의 변화들이 인터-노드 트랜스포트를 통한 데이터 이동을 필요로 하지 않는다.

DVO 시스템은 스토리지 매니저를 위해 XML 도큐먼트들을 관리하는 빌딩 블럭들로서 사용될 수 있는 기본 객체들을 제공하며 3개의 기능적인 부분들로 분할된다. DVO 데이터베이스(610)는 각각의 프로세스 내에서 DVO 로컬 컨텍스트를 취급하는 객체들 및 데이터베이스 내에 포함된 오픈 데이터베이스 및 해당 데이터베이스 내의 도큐먼트들을 포함하는 공유 테이블들을 포함한다. DVO에서, "데이터베이스"는 개념적인 스토리지 컨테이너들이며 임의의 종류의 스토리지 서비스(609) 내에 최종적으로 저장된 객체들을 전달할 수 있다. DVO 도큐먼트는 스토리지 매니저의 클라이언트에 대해 가시적인 XML 또는 이진 도큐먼트와 연관된다. 또한, DVO 도큐먼트들은 집합과 연관된 인덱스들 및 메타데이터를 포함하도록 사용된다.

DVO 타입들(612)은 하이 레벨 데이터 모델 구성들을 구현하도록 DVO 도큐먼트들 내에 사용될 수 있는 한 세트의 객체 클래스들이다. DVO 타입은 간단한 데이터 객체들부터 복잡하고 확장 가능한 인덱스 구조들까지 여러 가지이다. 각각의 DVO 타입은 2개의 클래스로 구현된다. 하나는 객체 레퍼런스들 내의 메모리 포인터들을 사용하는 "비공유 클래스"이고 다른 하나는 객체 레퍼런스들에 대해 논리적인 어드레스들, 소위 데이터베이스 포인터들을 사용하는 "공유 클래스"이다. "공유 클래스"는 2개의 서브 형태를 갖는다. 하나는 공유 DSM 영역 내의 객체의 표현이고 다른 하나는 객체 저장 데이터베이스 내의 디스크 상에 저장된 객체의 표현이다. DVO 시스템(607)은 그들의 공유 및 비공유 구현들 사이에서 객체들을 전송하는 메소드들을 제공한다.

상이한 DVO 타입들이 표 2에 나타나 있다.

DVO 타입

설명

Binary Document B-tree Index Btree Node Collection Document Document Extendible Hashing FlatCollectionDocument FlatDocument FlatNode Node Ordered Bucket Ordered Index

이진데이터를 취급하는 도큐먼트의 종류. b-트리 인덱스의 루트의 형태. 이는 루트 인덱스 노드의 어드레스뿐만 아니라 인덱스의 기술을 포함. 하나 이상의 키들에 의해 분류된 다양한 수의 레코드를 포함할 수 있는 B트리 인덱스의 단편. Collection document들을 취급하는 일종의 도큐먼트. 도큐먼트 메소드에 추가하여, 집합 디스크럽터를 다루는 메소드, 집합 내의 인덱스들 및 판독마크를 가짐. Open, Close, Create, 및 Write와 같은 공통 방법들을 이어받는 다른 도큐먼트 타입들에서 나온 베이스 타입. "Extendible Hashing-A Fast Access Method for Dynamic Files", Ronald Fagin, JurgNievergelt, Nicholas Pippenger, H. Raymond Strong. AcM Transactions on Database Systems 4(3), p315-344, 1979에 정의된 확장 가능한 해싱의 형태 구현. 공유 영역들에 사용된 특수한 종류의 CollectionDocument. 공유 영역들에 사용된 특수한 종류의 XMLDocument. 공유 영역들에 사용된 특수한 종류의 Node. XML 엘리먼트들을 저장하는 데 사용되는 타입. 이는 엘리먼트명, 엘리먼트의 부모, 엘리먼트 콘텐츠, 엘리먼트 속성, 다른 엘리먼트에 대한 링크, 및 변화 통지를 관리하는 메소드를 가짐. 키 기준 정렬(정수, 더블, 열)을 지원하는 일종의 인덱스. 대조된 데이터 벡터를 제공하는 타입. 이는 키/데이터 쌍을 추가, 제거, 및 변화시키고, 인덱스 커서를 관리하고, 부모 및 서브 인덱스를 관리하기 위한 메소드를 가짐.

DVO 타입	설명
Ordered Index Types Ordinal Ordered index Red-Black Index W32BinaryDocument XML Document	정렬된 인덱스 내에 저장될 수 있는 데이터 타입, 소위 레코드 및 필드. 서열적(ordinal) 어드레싱을 지원하는 일종의 인덱스. 이는 위치(예를 들어, vec[14])에 의해 임의의 엔트리가 어드레싱되도록 하는 벡터와 개념적으로 유사함. 인덱스 메소드외에, 엔트리를 인덱스 내의 특정 위치로 이동시키는 메소드를 가짐. red-black binary tree 알고리즘을 사용하여 밸런싱을 구현하는 일종의 정렬된 인덱스. 32비트 윈도우 플랫폼을 위한 특수 종류의 이진 도큐먼트. XML 도큐먼트를 취급하는 일종의 도큐먼트. 도큐먼트 메소드 외에, 이는 스키마 및 인덱스를 취급하는 메소드를 가짐.

DVO 시스템(607) 객체는 물리적인 저장 및 프로세스 로컬리티(locality) 이슈들로부터 DVO의 상부 레벨들을 분리시킨다. DVO 시스템 객체는 홈 프로세스로 그리고 홈 프로세스로부터의 요청들을 호출 및 취급하기 위한 DSM을 사용한다. 요청들은 데이터베이스를 열고, 닫고, 삭제하고, 데이터베이스 내에서 도큐먼트들을 찾고, 데이터베이스 도큐먼트들을 열고, 닫고, 삭제하고, 기입하는 것과 같은 동작들을 포함한다. 또한, 마스터 프로세스(600) 내의 DVO 시스템(607)은 스토리지 서비스(609)로부터 DVO 객체들을 검색할 수 있다. 서비스(609)와 같은 스토리지 서비스는 영구 매체에 정보를 저장 및 검색하는 유틸리티 프로그램이며 컨테이너, 데이터베이스, 또는 파일의 물리적인 통합성을 책임진다. 이는 모든 업데이트들이 내구성이 있으며 모든 내부 데이터 구조들(예를 들어, 리다이렉션 테이블, 공간 할당 맵)이 항상 디스크 상에서 일관됨을 보장한다. 프로세스 602와 같은 다른 프로세스들은 스토리지 서비스(609)를 직접 억세스할 수 없지만, DSM 영역(624)을 통해 간접적으로 시스템을 억세스할 수 있다.

스토리지 매니저(605)는 컨테이너 또는 객체 저장, 스트림 파일 시스템, 및 ZIP 파일들을 포함하는 상이한 형태의 물리적인 스토리지 시스템들과 함께 동작할 수 있다. 아토믹 코밋(atomic commit)을 달성하기 위해, 객체 저장 스토리지 서비스는 페이지 지향(page-oriented) 입력/출력 동작 및 핑-퐁 섀도우 페이지 테이블을 사용하여 구현될 수 있다.

개별적인 스토리지 매니저 메소드는 매우 작다. 다중 스토리지 매니저 동작, 심지어 상이한 도큐먼트들에 대한 동작들도 "트랜잭션"으로 그룹화될 수 있다. 트랜잭션은 단지 XML 데이터 통합성을 보호할 뿐만 아니라, 이들은 또한 그들이 스토리지 매니저가 영역 락 동작의 수와 메시시 패싱 시스템을 통한 데이터의 이동량을 감소시키도록 하기 때문에 성능을 향상시킬 수 있다.

스토리지 매니저는 프리미티브들이 다중 프로세스들 또는 컴퓨터들에서 일치성을 보증하는 DSM 도큐멘테이션에서 기술된 DSM 동기화 프리미티브 상에 구축된 판독-기입 및 판독-전용 트랜잭션 모두를 지원한다. 판독-기입 트랜잭션은 한 세트의 데이터베이스 판독 및 기입 동작들의 원자성 및 일치성을 위해 제공된다. 트랜잭션의 일부로서 변화되는 각각의 영역은 트랜잭션이 수용되거나 취소될 때까지 "락"된 상태로 유지될 것이다. 이는 트랜잭션의 일부가 아닌 동작들이 변화를 참조하는 것을 방지한다. 또한, 각각의 트랜잭션은 트랜잭션이 (명확한 API 콜 또는 예외의 결과로서) 취소된다면, 트랜잭션의 효과가 하지 않은 상태가 되도록 그것이 수정한 영역의 "이전 이미지"를 저장한다. 성능 요구도에 따라, 대안적인 구현은 전체 "이전 이미지"를 저장하기 보다 언두 정보(undo information)를 기입하는 것이다. 판독-전용 트랜잭션은 판독-기입 트랜잭션과 동일한 인터페이스를 사용한다. 판독-전용 트랜잭션은 다중 판독 동작이 일관되도록 보장해준다. 다른 트랜잭션들과 같이, 판독 전용 트랜잭션은 DSM 함수들을 사용하여 종료할 때까지 모든 판독 영역들을 "판독 상태"로 유지한다.

또한, 변화가 영구적이도록 보장하고 스토리지 매니저 동작들이 지속적으로 제공되도록 체크 포인트들이 사용될 수 있다. 체크 포인트들은 데이터 복구 로깅(data recovery logging)과 함께 사용된다. 모든 작업들은 그들이 수행될 때 "redo" 정보를 순차적인 복구 로그 파일에 기입한다. 체크 포인트가 수행될 때, 복구 로그 파일은 영구적 스토리지로 플러싱될 것이며 동작이 복구될 수 있도록 보장할 것이다. 트랜잭션들은 그들이 수행될 때까지 "redo" 정보를 기입하지 않으므로, 체크 포인트 동작이 트랜잭션의 중간에서 시작된다면, 그 트랜젝션 동작은 플러싱(flushing)되지 않을 것이다.

트랜잭션들은 쓰레드 및 데이터베이스로 스코프된다. 트랜잭션이 특정한 데이터베이스에 대한 쓰레드 상에서 시작되면, 그 트랜잭션은 그 데이터베이스 및 쓰레드 상의 모든 후속하는 스토리지 매니저 동작들에 대해 자동적으로 사용될 것이다. 종래의 운영 체제 쓰레드들의 확장이 사용되어, 트랜젝션들은 그루브 시스템의 간단한 마셜러(marshaler)를 사용하여 다른 쓰레드들, 예를 들어, 사용자 인터페이스 쓰레드로 안내될 필요가 있는 콜들을 올바르게 취급하게 된다. 시작된 트랜잭션을 갖지 않는 쓰레드 및 데이터베이스 상의 스토리지 매니저 호출에 의해 스토리지 매니저가 콜이 종료하기 바로 전에 수행될 "디폴트 트랜잭션"을 생성하게 될 것이다. 진행중인 트랜잭션을 이미 가지고 있는, 쓰레드 및 데이터베이스 상에서 새로운 트랜잭션을 시작하게 되면, 새로운 트랜잭션이 기존의 트랜잭션 내에 자동적으로 "포함"될 것이다. 포함된 트랜잭션들은 외부 트랜잭션 내에 시스템을 롤 백(roll back)시키는 능력을 제공한다. 특히, 내부, 포함된 트랜잭션들은 최외측 트랜잭션이 수행될 때까지 최종적으로 수행되지 않는다. 예를 들어, 포함된 트랜잭션이 수행되지만, 포함하는 트랜잭션이 후에 취소된다면, 포함된 트랜잭션은 취소될 것이다.

본 발명의 바람직한 실시예에서, 스토리지 매니저는 객체 지향 환경에서 구현된다. 따라서, 스토리지 매니저 그 자체와 도큐먼트들, 엘리먼트들, 실체들 등과 같은 모든 도큐먼트 컴포넌트들 모두는 객체들로서 구현된다. 이러한 객체들, 그 인터페이스, 하부 구조, 및 스토리지 매니저와 인터페이스하는 데 사용되는 API는 도 8에 도시되어 있다. API는 도 9 내지 도 11과 함께 보다 상세히 설명된다. 도 8을 참조하면, 스토리지 매니저는 도큐먼트 조작 API(802)를 통해 도큐먼트들에 대한 공유 억세스를 제공하지만, 클라이언트 어플리케이션들에 대한 전체 프로그래밍 모델을 가능하게 하기 위해, 도큐먼트의 컨텍스트 내에 추가 통신 및 동기 동작들이 제공된다. 예를 들어, 스토리지 매니저는 한 프로세스가 엘리먼트를 큐 API(804)를 통해 다른 프로세스로 전송하도록 하는 큐잉된 엘리먼트 동작들을 제공한다. 엘리먼트들은 값(전체 엘리먼트의 카피)에 의해 또는 엘리먼트에 대한 레퍼런스에 의해 전송될 수 있다. 또한, 하나 이상의 쓰레드들이 소저의 큐로 엔큐잉되는 엘리먼트들을 기다리도록 동기화 동작들이 제공된다. 또한, 스토리지 매니저는 RPC API(804)를 통해 RPC-스타일 엘리먼트 통신 및 동기화를 제공한다.

다른 클라이언트 컴포넌트들은 도큐먼트들이 스토리지 매니저에서 생성되거나 삭제될 때를 알 필요가 있을 것이다. 따라서, 스토리지 매니저는 인터페이스를 통지 API(800)를 통해 그 클라이언트 컴포넌트들에 대한 관심 기반 통지 시스템에 제공한다. 통지 시스템(806)은 도큐먼트가 생성되거나 삭제될 때 관심을 등록한 클라이언트 컴포넌트들에 통지를 제공한다.

도큐먼트 데이터는 데이터베이스 객체들, 도큐먼트 객체들, 엘리먼트 객체들, 및 스키마 객체들(808)을 포함하는 객체들의 집합에 의해 표현된다. 객체들은 도큐먼트 조작 API(802)에 의해 직접 조작될 수 있다.

도큐먼트 관련 객체들(808)은 위에서 상세히 논의되었던 분산 가상 객체 시스템(810)에 의해 실제로 구현된다. 분산 가상 객체 시스템(810)은 또한 큐 및 RPC API(804)의 제어를 받아 엘리먼트 큐 및 RPC 객체들(812)에 의해 조작될 수 있다.

분산 가상 객체 시스템(810)은 인터페이스(814)를 통해 분산 공유 메모리와 통신하며 인터페이스(816)를 통해 로깅 동작들과 통신한다. 유사하게, 분산 가상 객체 시스템은 인터페이스(818)를 통해 스토리지 서비스들과 상호 작용할 수 있다.

다음은 본 발명의 스토리지 매니저의 바람직한 실시예를 구현하는 데 사용되는 객체들 각각에 대한 인터페이스들에 대한 설명이다. 이러한 객체는 Microsoft Corporation, Redmond, Washington에 의해 보급된 공통 객체 모델(COM)에 따라 설계되며, COM 객체들로서 메모리 내에서 조작될 수 있다. 그러나, COM은 단지 하나의 객체 모델이며 인터페이스 방법론의 한 세트이다. 또한, 본 발명은 제한하는 것은 아니지만 자바 및 CORBA 객체 모델들을 포함하는 다른 스타일의 인터페이스 및 객체 모델들을 사용하여 구현될 수 있다.

도 9는 스토리지 매니저 객체에 대한 객체 인터페이스들을 도시하고 있다. 인터페이스(900)(IGrooveStorageManager)는 스토리지 매니저를 위한 기본 프레임워크를 캡슐화한다. 이러한 인터페이스는 COM 모델에 의해 정의된 공통 클래스인 IDispatch 인터페이스의 서브클래스이다. 표 3은 스토리지 매니저 인터페이스 내에 포함된 메소드들을 정의한다.

Interface IgrooveStorageManager : IDispatch

CreateDatabase(BSTR i_DatabaseURI, VARIANT_BOOL i_Temporary, VARIANT_BOOL i_SingleProcess, IUnknown* i_pSecurityContext, VARIANT_BOOL i_CreateOnCheckpoint, IgrooveDatabase**o_ppDatabase); CreateOrOpenDatabase(BSTR i_DatabaseURI, VARIANT_BOOL i_Temporary, VARIANT_BOOL i_SingleProcess, IUnknown* i_pSecurityContext, VARIANT_BOOL i_CreateOnCheckpoint, VARIANT_BOOL*o_pCreated, IgrooveDatabase**o_ppDatabase); CreateTemporaryElement(BSTR i_Name, lunknown*i_pParent, IgrooveElement**o_ppElement); CreateTemporaryXMLDocument (BSTRi_NamePrefix, BSTR i_SchemaURI, IUnknown* i_pAdditionalSchemaURIs, IgrooveXMLDocument** o_ppXMLDocument);

데이터베이스 생성. 데이터베이스는 일시적 또는 영구적일 수 있으며, 단일 또는 다중 프로세스일 수 있음. Database URI는 데이터베이스의 위치를 특정함. 새로운 데이터베이스를 생성하거나 기존의 데이터베이스를 오픈. 일시적인 엘리먼트를 생성. 유일한 URI를 가진 비어 있는 일시적 도큐먼트 생성.

Interface IgrooveStorageManager : IDispatch

Create Transform (BSTR i_CollectionDescriptorURI, BSTR i_SencondaryDescriptorURI, BSTR i_CollectionDescriptorName, IgrooveTransform**o_ppTransform); DeleteDatabase(BSTR i_DatabaseURI); IsHomeProcess(VARIANT_BOOL* o_pHomeProcess); OpenCrossProcessSemaphore(BSTR i_Name, VARIANT_BOOL i_Reentrant, IgrooveCrossProcessSemaphore** o_ppSemaphore); OpenDatabase(BSTR i_DatabaseURI, VARIANT_BOOL i_SingleProcess, lunknown*i_pSecurityContext, IgrooveDatabase**o_ppDatabase); OpenDatabaseURIEnum(IgrooveBSTR Enum**o_ppDatabaseURI);

트랜스포메이션 인터페이스 생성. 데이터베이스 삭제. 우리가 홈 프로세스인 지를 판정. 상이한 프로세스들 내의 동작을 동기화시키는 데 사용될 수 있는 세마포어 객체를 생성. 세마포어 객체가 리엔트란트(Reentrant)가 아니라면, 동일한 쓰레드 내에서 세마포어를 락하는 시도가 반복되어 프로세스가 차단될 것임. 기존의 데이터베이스 오픈. 현재 열려 있는 데이터베이스들의 계수(enumeration)를 리턴.

다른 인터페이스(902)(IGrooveStorageURISyntax)가 유니폼 리소스 식별자(URI들)의 형식인 표준명의 부분들 상에서 동작을 수행할 필요가 있는 스토리지 매니저의 클라이언트에 의해 사용된다. 표 4는 IGrooveStorageURISyntax 인터페이스를 위한 메소드들을 포함하고 있다.

Interface IGrooveStorageURISyntax : IDispatch

BuildDatabase(BSTR i_ServiceName, BSTR i_DatabasePath, VARIANT_BOOL i_Relative, BSTR*o_pURI); BuildDocumentURI (BSTR i_ServiceName, BSTR i_DatabasePath, BSTR i_DocumentName, VARIANT_BOOL i_Relative, BSTR*o_pURI); MakeAbsolute(BSTR i_RelativeURI, BSTR*o_pAbsoluteURI); MakeRelative(BSTR i_AbsoluteURI, BSTR*o_pRelativeURI); OpenDatabasePath(BSTRI_URI, BSTR*o_pDatabasePath); OpenDatabaseName(BSTRI_URI, BSTR*o_pDatabaseName); OpenPersist RootPath(BSTR* o_pPath); OpenServiceName(BSTRi_URI, BSTR*o_pServiceName); Parse(BSTRi_URI, BSTR* o_pServiceName, BSTR* o_pDatabasePath, BSTR* o_pDocumentName);

그 단편으로부터 데이터베이스 URI를 구축. 그 단편으로부터 도큐먼트 URI를 구축. 데이터베이스의 범위 내의 상대 URI가 주어지면, 절대 URI를 리턴. 데이터베이스 내의 절대 URI가 주어지면, 데이버에스 범위 내의 상대 URI 리턴. URI의 디렉토리 경로 부분 리턴. URI의 도큐먼트명 부분 리턴. 그루브 영구 데이터 디렉토리들의 루트로 디렉토리 경로 리턴. URI의 스토리지 서비스부 리턴. 주어진 URI의 단편들을 파싱.

도 10은 통지 시스템 인터페이스들을 도시하고 있다. 인터페이스(1000) (IGrooveLinkCallback)는 링크에 대한 정의가 발견될 때 XML 도큐먼트 또는 엘리먼트의 입력 프로세싱 동안에 통지될 필요가 있는 스토리지 매니저의 클라이언트에 의해 사용되기 위한 인터페이스이다. 인터페이스는 표 5에 정의된 메소드들을 포함한다.

Interface IgrooveLinkCallback : IDispatch
HandLink(IGrooveElement* i_pLinkElement, IgrooveByteInputStream* i_pLinkData);	특정된 엘리먼트가 링크 속성 정의를 포함할 때 호출됨.

XML 도큐먼트들 내의 엘리먼트들 상에서 원격 절차 호출(RPC들)을 취급할 필요가 있는 스토리지 매니저의 클라이언트에 의해 다른 인터페이스(1002) (IGrooeRPCServerCallback)가 사용된다. RPC 서버 콜백들은 "util" 베이스 클래스(후술됨)의 서브클래스이고, 다시 말해{즉} IGrooveElementUtilBase를 위한 모든 메소드들은 IGroove RPCServerCallback에도 적용된다. 표 6은 스토리지 매니저 RPC 서버 콜백 인터페이스에 사용된 메소드들을 정의한다.

Interface IGrooveElementRPCServerCallback : IDpatch
HandCall(IGrooveElement* i_pinput, IgrooveElement** o_ppOutput);	RPC 취급, 입력 엘리먼트 내의 입력 파라미터들 수신, 및 출력 엘리먼트 내의 출력 파라미터 리턴.

도 11, 도 12, 및 도 13은 도큐먼트 조작 인터페이스 및 큐 및 RPC 인터페이스들을 도시하고 있다. 특히, 도 11은 데이터베이스들을 조작하는 데 사용되는 인터페이스들을 도시하고 있다. 인터페이스(1100)(IGrooveDatabase)는 도큐먼트들이 저장되는 데이터베이스를 관리할 필요가 있는 스토리지 매니저의 클라이언트에 의해 사용된다. 이는 표 7 내의 메소드들을 포함한다.

Interface IGrooveDatabase : IDispatch

Checkpoint(); ClearDataLost(); CreateBainaryDocumentFromStream (IgrooveByteInputStream*i_pStream, BSTR I_DocumentName, IgrooveBinaryDocument** o_ppDocument); CreateOrOpenXMLDocument(BSTR i_DocumentName, BSTR i_RootElementName, BSTR i_SchemaURI, IUnknown* i_pAdditionalSchemaURIs, VARIANT_BOOL*o_pCreated, IGrooveXMLDocument** o_ppDocument); CreateXMLDocument(BSTR i_DocumentName, BSTR i_RootElementName, BSTR i_SchemaURI, IUnknown* i_pAdditionalSchemaURIs, IGrooveXMLDocument** o_ppDocument); CreateXMLDocumentFromStream (IGrooveByteInputStream*i_pStream, GrooveParseOptions i_ParseOptions, BSTR i_DocumentName, BSTR i_SchemaURI, IUnknown* i_pAdditionalSchemaURIs, lunknown* i_pLinkCallback, IGrooveXMLDocument** o_ppDocument); DeleteDocument(BSTR i_DocumentName);

데이터베이스에 대한 상태 지속 가능한 포인트를 생성. 데이터베이스가 열려있거나 최종 트랜잭션이 수행되었으므로 데이터가 상실되었을 수 있음을 지시하는 데이터베이스 플래그를 클리어함. 데이터베이스 내에 특정 네임을 가진 이진 도큐먼트를 생성. 특정 XML 도큐먼트를 오픈; 이미 존재하지 않는다면 특정된 네임 및 스키마를 가진 비어 있는 도큐먼트를 생성. 데이터베이스 내의 특정된 네임과 스키마를 가진 비어 있는 XML 도큐먼트를 생성. XML도큐먼트에서 지원되는 캐릭터 세트 엔코딩들 중 하나를 표현하는 바이트의 스트림(stream of bytes)이 주어지면, 데이터베이스 내에 XML 도큐먼트를 생성. 명명된 도큐먼트 삭제.

Interface IGrooveDatabase : IDispatch

DocumentEXists(BSTR i_DocumentName, VARIANT_BOOL* o_pDocumentExists); IsTransactionInProgress (VARIANT_BOOL* o_pTransactionInProgress); OpenBinaryDocument(BSTR i_DocumentName, IGrooveBinaryDocument** o_ppDocument); OpenCrossProcessSemaphore(BSTR i_Name, VARIANT_BOOL i_Reentrant, IgrooveCrossProcessSemaphore** o_ppSemaphore); OpenDocumentNameEnum (VARIANT_BOOL i_OpenOnly, IGrooveBSTREnum** o_ppDocumentNames); OpenTransaction(VARIANT_BOOL i_BeginLock, VARIANT_BOOL i_ReadOnly, VARIANT_BOOL i_BeginTransaction, VARIANT_BOOL i_Reentrant, BSTR i_LockName, IGrooveTransaction** o_ppTransaction OpenURI(BSTR*o_pDatabaseURI); OpenXMLDocument(BSTR i_DocumentName, IGrooveXMLDocument** o_ppDocument); WasDataLost(VARIANT_BOOL* o_pDataLost);

특정된 도큐먼트 네임이 주어지면, 데이터베이스 내의 도큐먼트의 존재에 대해 체크. 트랜잭션이 진행중이라면 TRUE를 리턴 특정된 이진 도큐먼트 오픈. 새로운 크로스 프로세스 동기화 객체를 생성. 네임이 특정되지 않았다면, 데이터베이스에 대한 디폴트 네임이 사용됨. 세마포어 (semaphore)가 리엔트란트(Reentrant)가 아니라면, 동일 쓰래드내의 세마포어를 락하는 시도를 반복하고 프로세스는 차단될 것임. 데이터베이스 내의 현재 도큐먼트들의 계수를 리턴. 데이터베이스 상에 새로운 트랜잭션을 생성. BeginLock는 데이터베이스 크로스 프로세스 세마포어가 락되어야하는 지를 특정함. BeginTransaction은 트랜잭션이 현재 시작되어야 하는 지를 특정함. LockName가 특정되지 않았다면, 데이터베이스에 대한 디폴트 네임이 사용됨. 세마포어가 리엔트란트가 아니라면, 동일 쓰래드 내의 세마포어를 락하는 시도를 반복하고 프로세스는 차단됨. 데이터베이스에 대한 URI를 리턴. 특정된 XML 도큐먼트를 오픈. 데이터베이스가 오픈되었거나 최종 트랜잭션이 수행되었으므로 데이터가 상실되었는 지를 나타내는 플래그의 값을 리턴

표 8은 프로세스들 사이의 억세스를 동기화할 필요가 있는 스토래지 매니저의 클라이언트에 대한 인터페이스(1102)(IGrooveCrossProcessSemaphore)를 위한 메소드들을 도시하고 있다.

Interface IgrooveCrossProcessSemaphore : IDispatch
DoLock(VARIANT_BOOL i_ReadOnly); DoUnlock();	세마포어 락. ReadOnly가 TRUE라면, 검색 동작들만이 데이터베이스 상에서 수행될 수 있으며, 그렇지 않으면, 임의의 동작이 수행될 수 있음. 세마포어 언락.

표 9는 데이터베이스 내의 동작들을 그룹화할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1104)(IGrooveTransaction)를 도시하고 있다. 트랜잭션들은 크로스-프로세스 세마포어들의 서브클래스이고, 다시 말해{즉} IGrooveCrossProcess Semaphore에 대한 모든 메소드들은 또한 IGrooveTransaction에도 적용된다. 스토리지 매니저 트랜잭션 인터페이스는 다음의 메소드들을 포함한다.

Interface IGrooveTransaction : IGrooveCrossProcessSemaphore
Abort(); Begin(VARIANT_BOOL i_ReadOnly); BeginIndependent(VARIANT_BOOL i_ReadOnly); Commit();	트랜잭션 종료. 트랜잭션의 시작시부터 데이터베이스에 행하여진 모든 작업이 버려짐. 트랜잭션 시작. ReadOnly가 잘못되었다면, 데이터베이스가 갱신될 수 있음. 쓰레드에 대한 다른 트랜잭션 시작. 단지 하나의 독립적 트랜잭션이 쓰레드 당 허용됨. 트랜잭션 종료. 트랜잭션의 시작시부터 데이터베이스에 행하여진 모든 작업이 신뢰성 있게 데이터베이스 내에 저장됨.

도 12는 스토리지 매니저의 클라이언트들이 도큐먼트들 내의 도큐먼트들 및 엘리먼트들을 조작하도록 하는 인터페이스들을 도시하고 있다. 표 10은 데이터베이스 내의 도큐먼트들을 관리할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1200)(IGrooveDocument)를 도시하고 있다. 스토리지 매니저 도큐먼트 인터페이스는 다음의 방법들을 포함한다.

Interface IGrooveDocument : IDispatch
OpenCrossProcessSemaphore(BSTR i_Name,VARIANT_BOOL i_Reentrant, IgrooveCrossProcessSemaphore** o_ppSemaphore); OpenDatabase(IgrooveDatabase** o_ppDatabase); OpenName(BSTR* o_pDocumentName); OpenURI(BSTR*o_pURI);	새로운 크로스 프로세스 동기화 객체를 생성. 네임이 특정되지 않았다면, 도큐먼트에 대한 URI가 사용됨. 세마포어가 리엔트란트가 아니라면, 동일 쓰레드 내의 세마포어를 락하는 시도를 반복하고 프로세스가 차단될 것임. 이 도큐먼트를 포함하는 데이터베이스 객체에 인터페이스를 리턴. 도큐먼트 네임 리턴. 이 도큐먼트를 식별하는 URI 복귀.

표 11은 데이터베이스 내의 XML 도큐먼트들을 관리할 필요가 있는 스토리지 매니저의 클라이언트를 위한 인터페이스(1202)(IGrooveXMLDocument)를 도시하고 있다. XML 도큐먼트들은 도큐먼트들의 서브클래스이고, 다시 말해 IGrooveDocument를 위한 모든 메소드들이 IGrooveXMLDocument에 적용된다. 스토리지 매니저 XML 도큐먼트 인터페이스는 다음의 메소드들을 포함한다.

interface IGrooveXMLDocument : IGrooveDocument
GenerateGrooveID(BSTR i_GrooveIDBase, double* o_pGrooveID); ConvertGrooveIDToSerializedGroovel D(double i_GrooveID, BSTR* o_pGrooveIDString);	스트링 식별자 I_GrooveIDBase로부터 8바이트 식별자를 생성. 8바이트 식별자를 i_GrooveID 스트링으로 변환.

interface IGrooveXMLDocument : IGrooveDocument

ConvertSerializedGrooveIDToGrooveI D(BSTR i_GrooveIDString, double* o_pGrooveID); CreateElement(BSTR i_Name, IUnknown*i_pParent, IgrooveElement **o_ppElement); CreateElementCopy(IgrooveElement* i_pSource, IGrooveElement* i_pParent, VARIANT_BOOL i_ShallowCopy, IgrooveElement** o_ppElement); CreateElementFromSchema(BSTR i_Name, IGrooveElement*i_pParent, IGrooveElement**o_ppElement); CreateElementFromStream (IGrooveByteInputStream*i_pStream, GrooveParseOptions i_ParseOptions, IUnknown*i_pParent, Iunknown* i_pLinkCallback, IgrooveElement** o_ppElement); CreateLocator(IGrooveLocator** o_ppLocator); FindElementByID(BSTR i_ID, IGrooveElement**o_ppElement, VARIANT_BOOL*o_pFound); OpenElementByID(BSTR i_ID, IGrooveElement**o_ppElement); OpenElementEnumByAttributeValue (BSTR i_ElementName, BSTR i_AttributeName, BSTR i_AttributeValue, IgrooveElementEnum **o_ppElementEnum);

그루브 식별자의 스트링 버전을 8바이트 버전으로 변환. 공급된 태그를 가진 새로운 엘리먼트 생성; 태그는 한번 생성되어 변경될 수 없음. 부모 레퍼런스가 공급되면, 새로운 엘리먼트가 그 부모의 자식으로서 생성됨. 새로운 엘리먼트를 부모 엘리먼트 하에 위치시키며, 특정된 엘리먼트들 및 그 모든 자식들의 깊은/얕은 카피를 수행(깊은 카피는 회귀적으로; 얕은 카피는 한 레벨만). 스키마 내의 엘리먼트의 정의와 일치하는 엘리먼트 생성. 엘리먼트, 그 속성, 및 임의의 자식 엘리먼트들을 생성. 파서를 사용하여, 엘리먼트 생성, 바이트 입력 스트림으로부터 판독, 및 텍스트 스트림으로부터 엘리먼트들 및 속성들을 필요한대로 생성, 그들을 다음에 호출자에 리턴되는 엘리먼트로 삽입. 부모 레퍼런스가 공급되면, 새로운 엘리먼트가 부모의 자식으로서 생성됨. 인터페이스를 새로운 로케이터 객체로 리턴. 특정된 ID의 엘리먼트 탐색 및 탐색되었다면 불리언 값을 리턴. 특정된 ID의 엘리먼트 탐색 특정된 값을 갖는 명명된 속성을 갖는 도큐먼트 내의 모든 엘리먼트들의 계수를 리턴.

interface IGrooveXMLDocument : IGrooveDocument

OpenElementEnumByAttributeValueAs Bool(BSTR i_ElementName, BSTR i_AttributeName, VARIANT_BOOL i_AttributeValue, IgrooveElementEnum **o_ppElementEnum); OpenElementEnumByAttributeValueAs Double(BSTR i_ElementName, BSTR i_AttributeName, double i_AttributeValue, IgrooveElementEnum **o_ppElementEnum); OpenElementEnumByAttributeValueAs Long(BSTR i_AttributeName, long i_AttributeValue, IgrooveElementEnum **o_ppElementEnum); OpenElementEnumByLocator(BSTR i_LocatorText, IgrooveElementEnum** o_ppElementEnum); OpenElementEnumByName(BSTR i_Name, IGrooveElementEnum** o_ppElementEnum); OpenMetaElement(IgrooveElement** o_ppElement); OpenRootElement(IgrooveElement** o_ppRootElement);

특정된 불리언 타입 값을 갖는 명명된 속성을 갖는 도큐먼트 내의 모든 엘리먼트들의 계수를 리턴. 특정된 더블 플로팅 타입 값을 갖는 명명된 속성을 갖는 도큐먼트 내의 모든 엘리먼트들의 계수를 리턴. 특정된 긴 정수 타입 값을 갖는 명명된 속성을 갖는 도큐먼트 내의 모든 엘리먼트들의 계수를 리턴. 특정된 엘리먼트 로케이터 표현을 만족시키는 모든 엘리먼트들에 대한 레퍼런스를 갖는 엘리먼트 계수기(enumerator)를 리턴. 만족하는 엘리먼트가 없으면,엘리먼트 계수기가 콘텐츠없이 생성될 것임. 특정된 태그 네임을 갖는 도큐먼트 내의 모든 엘리먼트들의 계수를 리턴. 이 XML 도큐먼트를 정의하는 메타 엘리먼트로 인터페이스를 리턴. 이 XML 도큐먼트에 대한 루트 엘리먼트를 오픈.

표 12는 데이터베이스 내의 이진 도큐먼트를 관리할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1204)(IGrooveBinaryDocument)를 위한 메소드를 나타내고 있다. 이진 도큐먼트들은 도큐먼트들의 서브클래스이고, 다시 말해 IGrooveDocument를 위한 모든 메소드들은 IGrooveBinaryDocument에도 적용된다.

interface IgrooveBinaryDocument : IGrooveDocument
OpenByteInputStream (IGrooveByteInputStream** o_ppByteInputStream);	이진 도큐먼트 내의 바이트들을 판독하는 데 사용될 수 있는 바이트 스트림 객체로 인터페이스를 리턴.

표 13은 소위 명세 XSLT에 정의된 바와 같은 로케이터 질의들을 사용하여 엘리먼트들을 탐색할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1206)(IGrooveLocator)를 나타내고 있다. XSLT의 세부{사항} 명세는 http://www.w3.org/TR/xslt에서 찾을 수 있다. 스토리지 매니저 로케이터 인터페이스는 다음의 메소드들을 포함한다.

interface IGrooveLocator : Idispatch

FindElement(BSTR i_LocatorStr, IGrooveElement*i_pContextElement, IGrooveElement**o_ppElement, VARIANT_BOOL*o_pFound); Invalidate(VARIANT_BOOL i_AssignNewIDs); OpenElementEnum(BSTR i_LocatorStr, IGrooveElement* i_pContextElement, VARIANT_BOOL i_Sort, BSTR i_SortConstraint, BSTR i_SortKey, GrooveSortOrder i_SortOrder, IgrooveElementEnum** o_ppElements); OpenElementEnumWithTumblers (BSTR i_LocatorStr, IgrooveElement *i_pContextElement, VARIANT_BOOL i_RelativeTumblers, IGrooveBSTREnum**o_ppTumblers, VARIANT_BOOL i_Sort, BSTR i_SortConstraint, BSTR i_SortKey, GrooveSortOrder i_SortOrder, IGrooveElementEnum** o_ppElements); OpenText(BSTR i_LocatorStr, IGrooveElement*i_pContextElement, BSTR*o_pValue);

컨텍스트 엘리먼트의 범위 내의 로케이터 스트링에 의해 특정된 탐색을 만족시키는 엘리먼트 객체로 인터페이스를 리턴. 인터페이스 인스턴스 내의 상태 정보를 클리어. 특정된 소팅 기준에 따라 대조된 로케이터 스트링을 일치시키는 모든 엘리먼트들의 계수기를 리턴. 컨텍스트 엘리먼트에 의해 포인트되는 엘리먼트들 상의 로케이터 스트링에 의해 특정된 탐색을 수행, 특정된 소팅 기준에 따라 대조된 매칭 엘리먼트들 뿐만아니라 각각의 매칭를 위한 텀블러 값들을 리턴. 컨텍스트 엘리먼트의 범위 내의 로케이터 스트링에 의해 특정된 탐색을 만족시키는 엘리먼트 또는 속성으로부터 텍스트를 리턴.

표 14는 XSLT에 정의된 바와 같이 XML 도큐먼트 트랜스포메이션을 수행할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1208) (IGrooveTransform)를 나타낸다. 스토리지 매니저 트랜스폼 인터페이스는 다음의 메소드들을 포함한다.

Interface IGrooveTransform : IDispatch
TransformXMLDocument (IGrooveXMLDocument* i_pXMLDocument, IgrooveElement* i_pStartElement, BSTR i_SortRule, long i_StartElementNum, long i_NumElements, IGrooveXMLDocument* io_pResultDocument, VARIANT_BOOL i_AlwaysOutputHeader, long* o_pElementsProcessed); TransformElement(IgrooveElement* i_pContextElement, BSTR i_TransformationTemplate, IGrooveXMLDocument** o_ppResultDocument);	ResultDocument에 있는 트랜스폼 결과를 리턴하는 입력 XML 도큐먼트를 트랜스폼. ResultDocument에 있는 트랜스폼 결과를 리턴하는 입력 컨텍스트 엘리먼트를 트랜스폼.

표 15는 스토리지 매니저의 클라이언트가 XML 도뮤먼트들 내의 엘리먼트들을 조작하도록 하는 인터페이스(1210)(IGrooveElement)를 나타내고 있다. 스토리지 매니저 엘리먼트 인터페이스는 다음의 메소드를 포함한다.

Interface IGrooveElement : Idispatch

AppendContext(BSTR i_Text, GrooveContentType i_Type); AppendContentElement (IGrooveElement*i_pElement); AppendContentProcessinginstruction (BSTR i_Target, BSTR i_Text); CreateElement(BSTR i_Name, IGrooveElement*i_pParent, IGrooveElement**o_ppElement); CreateElementCopy(IgrooveElement* i_pSource, IGrooveElement*i_pParent, VARIANT_BOOL i_ShallowCopy, IGrooveElement**o_ppElement); CreateElementFromSchema(BSTR i_Name, IGrooveElement*i_pParent, IGrooveElement**o_ppElement); CreateElementRPCClient (IGrooveElementRPCClinent **o_ppRPCClient); CreateElementRPCServer (IGrooveElementRPCServer** o_ppRPCServer); CreateElementRPCServerThread (IGrooveelementRPCServerCallback* i_pCallback, IGrooveElementRPCServerThread** o_ppRPCServerThread);

이 엘리먼트 내에 그 최종 타입으로서 콘텐츠의 종류를 삽입. 최종 콘텐츠 엘리먼트로서 엘리먼트를 삽입. 최종 프로세싱 명령으로서 타겟 Target를 사용하여 프로세싱 명령 삽업. 동일한 도큐먼트 내의 새로운 엘리먼트를 생성. 새로운 엘리먼트를 목적 도큐먼트에 위치시키며 특정된 엘리먼트 및 그 모든 자식들의 깊은/얕은 카피를 수행(깊은 카피는 회귀적으로; 얕은 카피는 한 레벨만). 리턴된 엘리먼트는 도큐먼트의 엘리먼트 트리에 부착되어야 함. 스키마내의 엘리먼트의 정의에 일치하는 엘리먼트 생성. 엘리먼트, 그 속성, 및 임의의 자식 엘리먼트 생성. 엘리먼트 RPC 클라이언트로 인터페이스를 생성 및 리턴. 엘리먼트 RPC 서버로 인터페이스를 생성 및 리턴. 엘리먼트 RPC 서버 쓰레드로 인터페이스를 생성 및 리턴.

Interface IGrooveElement : Idispatch

CreateLink(IGrooveDocument* i_pDocument, BSTR i_Title, BSTR i_Role, GrooveXLinkShow i_Show, GrooveXLinkActuate i_Actuate, GrooveXLinkSerialize i_Serialize); DecrementAttributeAsLong(BSTR i_Name,long*o_pOldValue); Delete(); DeleteAllAttributes(); DeleteAllContent(); DeleteAttribute(BSTR i_Name); DeleteContent(long i_Ordinal); DeleteLinkAttributes(); DetachFromParent(); DoesAttributeExist(BSTR_i Name, VARIANT_BOOL*o_pFound); Duplicate(IGrooveElement* i_pTargetElement, VAriANT_BOOL i_ShallowDuplicate); FindAttribute(BSTR i_Name, BSTR* o_pValue, VARIANT_BOOL* o_pFound);

특정된 XLink 파라미터들을 사용하여 다른 도큐먼트에 대한 링크를 생성. 긴 정수형 속성의 값으로부터 1 감산. 도큐먼트로부터 엘리먼트 영구 제거. 삭제된 엘리먼트에 대해 더 이상 수행되는 동작 없음. 엘리먼트로부터 모든 속성들을 제거. 엘리먼트로부터 모든 자식 콘텐츠 엘리먼튿르 및 텍스트를 제거하고 도큐먼트로부터 이들을 삭제. 엘리먼트로부터 명명된 속성을 제거. 엘리먼트로부터 특정된 위치에서 콘텐츠를 제거. 엘리먼트로부터의 링크들인 모든 속성들을 제거. 그 부모의 콘텐츠로부터 엘리먼트를 제거. 엘리먼트는 여전히 도큐먼트의 일부이며 해제되기전에 재부착 또는 파괴되어야 함. 속성이 엘리먼트 상에서 설정되는 지를 리턴. 속성, 및 만약 ShallowDuplicate가 FALSE라면 모든 파생 엘리먼트를 오버라이딩 (overriding)하면서 특정된 타겟 엘리먼트에 대해 이 엘리먼트의 복사를 만듬. 임의의 속성을 텍스트로서 얻음. 속성이 엘리먼트내에 존재하지 않으면, Found는 FALSE이고 리턴되는 값은 없음.

Interface IGrooveElement : Idispatch

FindAttributeAsBinary(BSTR i_Name, IGrooveByteInputStream**o_ppValue, VARIANT_BOOL*o_pFound); FindAttributeAsBinaryArray(BSTR i_Name, SAFEARRAY(BYTE)* o_ppValue, VARIANT_BOOL* o_pFound); FindAttributeAsBinaryToStream(BSTR i_Name, IgrooveByteOutputStream* i_pStream, VARIANT_BOOL o_pFound); FindAttributeAsBool(BSTR i_Name, VARIANT_BOOL*o_pValue, VARIANT_BOOL*o_pFound); FindAttributeAsDouble(BSTR I_Name, double*o_pValue, VARIANT_BOOL* o_pFound); FindAttributeAsGrooveID(BSTR i_Name, double*o_pValue, VARIANT_BOOL*o_pFound); FindAttributeAsLong(BSTR i_Name, long*o_pValue, VARIANT_BOOL* o_pFound);

임의의 소성을 이진으로서 얻음. 속성은 주어진 타입으로서 설정되거나 도큐먼트 스키마의 타입으로서 특정되어야 함. 속성이 엘리먼트 내에 있지 않다면, Found는 FALSE이고 리턴되는 값은 없음. 임의의 소성을 이진으로서 얻어 어레이 내의 값을 리턴. 속성은 주어진 타입으로서 설정되거나 도큐먼트 스키마의 타입으로서 특정되어야 함. 속성이 엘리먼트 내에 있지 않다면, Found는 FALSE이고 리턴되는 값은 없음. 임의의 소성을 이진으로서 얻어 스트림 내의 값을 리턴. 속성은 주어진 타입으로서 설정되거나 도큐먼트 스키마의 타입으로서 특정되어야 함. 속성이 엘리먼트 내에 있지 않다면, Found는 FALSE이고 리턴되는 값은 없음. 임의의 속성을 불리언으로서 얻음. 속성은 주어진 타입으로서 설정되거나 도큐먼트 스키마내의 타입으로서 특정되어야 함. 속성이 엘리먼트 내에 있지 않다면, Found는 FALSE이고 리턴되는 값은 없음. 임의의 속성을 더블로서 얻음. 속성은 주어진 타입으로서 설정되거나 도큐먼트 스키마내의 타입으로 특정되어야 함. 속성이 엘리먼트 내에 있지 않다면, Found는 FALSE이고 리턴되는 값은 없음. 임의의 속성을 그루브 식별자로서 얻음. 속성은 주어진 타입으로서 설정되거나 도큐먼트 스키마내의 타입으로서 특정되어야 함. 속성이 엘리먼트 내에 있지 않다면, Found는 FALSE이고 리턴되는 값은 없음. 임의의 속성을 롱으로서 얻음. 속성은 주어진 타입으로서 설정되거나 도큐먼트 스키마내의 형태로서 특정되어야 함. 속성이 엘리먼트 내에 있지 않다면, Found는 FALSE이고 리턴되는 값은 없음.

Interface IGrooveElement : Idispatch

FindAttributeAsVARIANT(BSTR i_Name, VARIANT*o_pValue, VARIANT_BOOL*o_pFound); FindContentElementByName(BSTR i_Name, IGrooveElement** o_ppElement, VARIANT_BOOL* o_pFound); FindContentElementByNameAndAttribute(BSTR i_Name, BSTR i_AttributeName, BSTR i_AttributeValue, IGrooveElement**o_ppElement, VARIANT_BOOL*o_pFound); FindParent(IGrooveElement** o_ppParent, VARIANT_BOOL* o_pFound); GetActuate(GrooveXLinkActuate* o_pActuate); GetAttributeCount(long*o_pCount); GetContentCount(long*o_pCount); GetContentType(long i_Ordinal, GrooveContentType*o_pType); GetOrdinal(long*o_pOrdinal); GetSerialize(GrooveXLinkSerialize* o_pSerizalize); GetShow(GrooveXLinkShow* o_pShow); IncrementAttributeAsLong(BSTR i_Name,long*o_pOldValue); InsertContent(long i_Ordinal, BSTR i_Text, GrooveContentType i_Type);

변동 가능한 값을 임의의 속성으로서 얻음. 속성이 엘리먼트 내에 존재하지 않으면, Found는 FALSE 이고 리턴되는 값은 없음. 엘리먼트의 컨텍스트 내에서, 특정된 태그 네임을 가진 엘리먼트 탐색. 그 엘리먼트가 탐색되지 않으면, Found는 FALSE이고 엘리먼트 레퍼런스는 리턴되지 않음. 이 엘리먼트의 컨텍스트 내에서, 특정된 태그 네임을 가진 엘리먼와 특정된 속성값을 가진 속성 네임을 탐색. 엘리먼트가 탐색되지 않으면, Found는 FALSE이고 엘리먼트 레퍼런스는 리턴되지 않음. 객체의 부모 엘리먼트를 얻음. 엘리먼트는 단지 단일 부모만을 가질 수 있고 단일 엘리먼트의 단일 콘텐츠 엔트리로부터만 레퍼런스될 수 있음. 엘리먼트가 부모를 갖지 않으면, Found는 FALSE이고 리턴되는 값은 없음. 엘리먼트의 링크 속성 내의 Actuate 파라미터의 값을 리턴. 엘리먼트가 갖는 속성의 수를 리턴. 엘리먼트의 콘텐츠및텍스트엔트리의 수를 리턴. 특정된 서열적 위치에서의 콘텐츠의 형태를 리턴. 엘리먼트의 부모 콘텐츠 내의 서열적 위치를 얻음. 엘리먼트의 링크 속성 내의 Serialize 파라미터의 값을 리턴. 엘리먼트의 링크 속성 내의 Show 파라미터의 값을 리턴. 긴 정수 타입 속성의 값에 1 가산. 특정된 서열적 위치에서의 텍스트 엔트리를 삽입.

Interface IGrooveElement : Idispatch

InsertContentElement(long i_Ordinal, IGrooveElement*i_pElement); InsertContentProcessingInstruction(long i_Ordinal,BSTR i_Target, BSTR i_Text); IsLinkElement(VARIANT_BOOL* o_plsLink); IsReferenced(VARIANT_BOOL* o_plsReferenced); IsSame(IGrooveElement*i_pElement, VARIANT_BOOL*o_plsSame); OpenAttribute(BSTR i_Name, BSTR *o_pValue); OpenAttributeAsBinary(BSTR i_Name, IGrooveByteInputStream**o_ppValue); OpenAttributeAsBinaryArray(BSTR i_Name, SAFEARRAY(BYTE)* o_ppValue); OpenAttributeAsBinaryToStream(BSTR i_Name, IgrooveByteOutputStream* i_pStream); OpenAttributeAsBool(BSTR i_Name, VARIANT_BOOL*o_pValue); OpenAttributeAsDouble(BSTR i_Name, double*o_pValue); OpenAttributeAsGrooveID(BSTR i_Name, double*o_pValue); OpenAttributeAsLong(BSTR i_Name, long*o_pValue);

특정된 서열적 위치에 엘리먼트 삽입. 특정된 서열적 위치에 타겟 Target을 가진 텍스트 프로세싱 명령을 삽입. 엘리먼트가 XLink 마크업을 포함하는 지를 판정. 엘리먼트가 레퍼런스되면 TRUE 리턴. 특정된 엘리먼트 객체가 엘리먼트이거나 엘리먼트와 동일하면 TRUE 리턴. 임의의 속성을 텍스트로서 얻음. 임의의 속성을 이진으로서 얻음. 속성은 주어진 타입으로 설정되거나 도큐먼트 스키마내의 타입으로서 특정되어야 함. 임의의 속성을 이진으로서 얻고 어레이 내의 값을 리턴. 속성은 주어진 타입으로서 설정되거나 도큐먼트 스키마 내의 타입으로서 특정되어야 함. 임의의 속성을 이진으로서 얻고 스트림 내의 값을 리턴. 속성은 주어진 타입으 로서 설정되거나 도큐먼트 스키마 내의 타입으로서 특정되어야 함. 임의의 속성을 불리언으로서 얻음. 속성은 주어진 타입으로서 설정되거나 도큐먼트 스키마 내의 타입으로서 특정되어야 함. 임의의 속성을 더블로서 얻음. 속성은 주어진 타입으로서 설정되거나 도큐먼트스키마 내의 타입으로서 특정되어야 함. 임의의 속성을 그루브 식별자로서 얻음. 속성은 주어진 타입으로서 설정되거나 도큐먼트 스키마 내의 타입으로서 특정되어야 함. 임의의 속성을 Long로서 얻음.속성은 주어진 타입으로서 설정되거나 도큐먼트스키마 내의 타입으로서 특정되어야 함.

Interface IGrooveElement : Idispatch

OpenAttributeAsVARIANT(BSTR i_Name, VARIANT*o_pValue); OpenAttributeEnum (IGrooveStringStringEnum** o_ppAttributes); OpenAttributeVariantEnum (IGrooveNameValueEnum** o_ppEnum); OpenBoundCode(IgrooveBoundCode** o_ppBoundCode); OpenContentComment(long i_Ordinal, BSTR*o_pComment); OpenContentElement(long i_Ordinal, IGrooveElement**o_ppElement); OpenContentElementByName(BSTR i_Name, IGrooveElement** o_ppElement); OpenContentElementByNameAndAtrribute(BSTR i_Name, BSTR i_AttributeName, BSTR i_AttributeValue, IGrooveElement**o_ppElement); OpenContentElementEnum (IGrooveElementEnum** o_ppElements); OpenContentElementEnumByName (BSTR i_Name, IgrooveElementEnum** o_ppElements); OpenContentElementEnumByNameAnd Attribute(BSTR i_Name, BSTR i_AttributeName, BSTR i_AttributeValue, IGrooveElementEnum**o_ppElements); OpenContentProcessingInstruction(long i_Ordinal, BSTR*o_pTarget, BSTR* o_pText);

임의의 속성을 변화 가능한 값으로서 얻음. 모든 엘리먼트의 속성들을 텍스트로서 열거. 모든 엘리먼트의 속성들을 변화 가능한 데이터 타입들로서 열거. 엘리먼트에 바인드된 객체의 인스턴스를 리턴. 특정된 서열적 위치에서 엘리먼트 내에 포함된 코멘트의 텍스트를 리턴. 특정한 서열적 위치에서 엘리먼트에 포함된 자식 엘리먼트 인터페이스를 리턴. 이 엘리먼트의 컨텍스트 내에서, 특정된 태그 네임을 가진 엘리먼트를 탐색하고 그 인터페이스를 리턴. 이 엘리먼트의 컨텍스트 내에서, 특정한 태그 네임을 가진 엘리먼트와 특정한 속성값을 가진 속성 네임을 탐색. 모든 자식 콘텐츠 엘리먼트(비회귀적)의 계수 리턴. 모든 차일트 콘텐츠 엘리먼트(비회귀적)의 계수 리턴. 주어진 네임을 갖는 엘리먼트들만이 리턴될 것임. 특정된 태그 네임 및 특정된 속성값을 갖는 속성명을 가진 엘리먼트의 범위 내의 모든 콘텐츠 엘리먼트의 계수 리턴. 특정된 서열적 위치에서의 XML 프로세싱 명령을 리턴.

Interface IGrooveElement : Idispatch

OpenContextProcessingInstructionTarget (long i_Ordinal, BSTR*o_pTarget); OpenContentProcessingInstructionText (long i_Ordinal, BSTR*o_pText); OpenContentText(long i_Ordinal, BSTR *o_pText); OpenContentTextEnum (IGrooveBSTREnum**o_ppText); OpenElementQueue (IGrooveElementQueue**o_ppText); OpenElementReferenceQueue (IgrooveElementReferenceQueue** o_ppQueue); OpenHRef(BSTR*o_pHref); OpenLinkAttributes(BSTR*o_pHref, BSTR*o_pTitle, BSTR*o_pRole, GrooveXLinkShow*o_pShow, GrooveXLinkActuate*o_pActuate, GrooveXLinkSerialize*o_pSerialize); OpenLinkBinaryDocument (VARIANT_BOOL i_SingleProcess, IUnknown*i_pSecurityContext, IGrooveBinaryDocument** o_ppDocument); OpenLinkedXMLDocument (VARIANT_BOOLi_SingleProcess, IUnknown*i_pSecurityContext, IGrooveXMLDocument** o_ppDocument); OpenMultiReaderElementQueueReader (IgrooveMultiReaderElementQueueReader **o_ppQueue);

특정된 서열적 위치에서의 XML 프로세싱 명령 의 타겟을 리턴. 특정된 서열적 위치에서의 XML 프로세싱 명령의 PI 텍스트 리턴. 특정된 서열적 위치에서의 컨텍스트 텍스트를 리턴. 텍스트 엔트리들을 열거(비회귀적). 엘리먼트 상에서 엘리먼트 큐를 생성. 엘리먼트 큐는 엘리먼트의 구조에 영향을 주지 않음. 인터페이스를 레퍼런스 큐 객체를 리턴. 엘리먼트의 링크 속성 내의 HREF 파라미터의 값을 리턴. 모든 표준 링크 엘리먼트들을 검색. 주 : 모든 속성은 의무적임. 엘리먼트의 링크 속성 내의 HREF 파라미터 내에서 레퍼런스된 이진 도큐먼트로 인터페이스를 리턴. 엘리먼트의 링크 속성 내의 HREF 파라미터 내에 레퍼런스된 XML 도큐먼트로 인터페이스를 리턴. 엘리먼트상에서 엘리먼트 다중-판독기(multi-reader)를 생성하고 판독기를 추가. 이는 엘리먼트의 구조를 변화시킬 수 있음.

Interface IGrooveElement : Idispatch

OpenMultiReaderElementQueueWriter (GrooveMultiReaderQueueOptions i_Options, IgrooveMultiReaderElementQueueWriter **o_ppQueue); OpenMultiReaderElementReferenceQueue Reader (IgrooveMultiReaderElementQueueReader **o_ppQueue); OpenMultiReaderElementReferenceQueue Writer (GrooveMultiReaderQueueOptions i_Options, IgrooveMultiREaderElementQueueWriter **o_ppQueue); OpenName(BSTR*o_pName); OpenParent(IGrooveElement** o_ppParent); OpenReadOnlyElement (VARIANT_BOOL i_AllowOpenParent, IGrooveReadOnlyElement** o_ppReadOnlyElement); OpenReference (IGrooveElementReference** o_ppElementReference); OpenRole(BSTR*o_pRole); OpenTitle(BSTR*o_pTitle); OpenURI(BSTR*o_pName); OpenXMLDocument (IGrooveXMLDocument** o_ppDocument);

엘리먼트상에서 엘리먼트 다중-기입기(multi-writer) 큐를 생성하고 기입기를 추가. 이는 엘리먼트 구조를 변화시킬 수 있음. 멀티리더 엘리먼트 레퍼런스 큐 리더 객체로 인터페이스를 리턴. 멀티리더 엘리먼트 레퍼런스 큐 라이터 객체로 인터페이스를 리턴. 엘리먼트의 태그 네임을 리턴. 객체의 부모 엘리먼트를 얻음. 엘리먼트는 단일 부모만을 가질 수 있고 단일 엘리먼트의 단일 콘텐츠 엔트리로부터만 레퍼런스될 수 있음. 이 엘리먼트로 판독 전용 엘리먼트 인터페이스를 리턴. 이 엘리먼트로 엘리먼트 레퍼런트 인터페이스를 리턴. 이 엘리먼트의 링크 속성 내의 Role 파라미터의 값을 리턴. 엘리먼트의 링크 속성 내의 Title 파라미터의 값을 리턴. URI를 엘리먼트로 리턴. 이 엘리먼트를 포함하는 XML 도큐먼트로 인터페이스 포인터를 리턴.

Interface IGrooveElement : Idispatch

Serialize(GrooveSerializeType i_Type, enum GrooveCharEncoding i_Encoding, GrooveSerializeOptions i_Options, IGrooveByteInputStream** o_ppStream); SerializeReturnAdditionalLinkedDocuments(GrooveSerializeType i_Type, enum GrooveCharEncoding i_Encoding, GrooveSerializeOptions i_Options, IGrooveDocumentEnum** o_ppStream); SerializeToStream (IGrooveByteOutputStream*i_pStream, GrooveSerializeType i_Type, enum GrooveCharEncoding i_Encoding, GrooveSerializeOptions i_Options); SerializeToStreamReturnAdditionalLinked Documents(IgrooveByteOutputStream *i_pStream, GrooveSerializeType i_Type, enum GrooveCharEncoding i_Encoding, GrooveSerializeOptions i_Options, IgrooveDocumentEnum** o_ppAdditionalLinkedDocuments); SetAttribute(BSTR i_Name, BSTR i_Value); SetAttributeAsBinary(BSTR i_Name, IGrooveByteInputStream*i_pValue); SetAttributeAsBinaryArray(BSTR i_Name, SAFEARRAY(BYTE)* i_pValue); SetAttributeAsBool(BSTR i_Name, VARIANT_BOOL i_Value); SetAttributeAsDouble(BSTR i_Name, double i_Value);

특정된 엔코딩 및 옵션들을 갖는 스트림으로 엘리먼트를 일련화함. 특정한 엔코딩 및 옵션들을 갖는 스트림으로 엘리먼트를 일련화함. 인터페이스들의 계수를 엘리먼트 및 모든 자손 내의 링크에 의해 리턴되는 도큐먼트로 리턴. 특정된 엔코딩 및 옵션들을 갖는 스트림으로 엘리먼트를 일련화함. 특정된 엔코딩 및 옵션들을 갖는 스트림으로 엘리먼트를 일련화함. 인터페이스들의 계수를 엘리먼트 및 모든 자손 내의 링크에 의해 레퍼런스되는 도큐먼트로 리턴. 임의의 속선을 텍스트로서 설정. 임의의 속성을 이진수로서 설정. 이 속성은 주어진 타입으로 설정되거나 도큐먼트 스키마의 타입으로서 특정되어야 함. 임의의 속성을 이진수로서 설정하고 어레이 내의 값을 리턴. 이 속성은 주어진 타입으로 설정되거나 도큐먼트 스키마의 타입으로서 특정되어야 함. 임의의 속성을 불리언으로서 설정. 이 속성은 주어진 타입으로 설정되거나 도큐먼트 스키마의 타입으로서 특정되어야 함. 임의의 속성을 더블로서 설정. 이 속성은 주어진 타입으로 설정되거나 도큐먼트 스키마의 타입으로서 특정되어야 함.

Interface IGrooveElement : Idispatch

SetAttributeAsGrooveID(BSTR i_Name, double i_Value); SetAttributeAsLong(BSTR i_Name, long i_Value); SetAttributeAsVARIANT(BSTR i_Name, VARIANT*i_pValue); SetContent(long i_Ordinal, BSTR i_Text, GrooveContentType i_Type); SetcontentElement(long i_Ordinal, IGrooveElement*i_pElement); SetContentProcessingInstruction(long i_Ordinal, BSTR i_Target,BSTR i_Text); SetContentTextEnum (IGrooveBSTREnum*i_pEnum); SetLinkAttributes(BSTR i_Href, BSTR i_Title, BSTR i_Role, GrooveXLinkShow i_Show, GrooveXLinkActuate i_Actuate, GrooveXLinkSerialize i_Serialize); SetName(BSTR i_Name); SetTempAttribute(BSTR i_Name, BSTR i_Value);

임의의 속성을 그루브 식별자로서 설정. 이 속성은 주어진 타입으로 설정되거나 도큐먼트 스키마의 타입으로서 특정되어야 함. 임의의 속성을 롱으로서 설정. 이 속성은 주어진 타입으로 설정되거나 도큐먼트 스키마의 타입으로서 특정되어야 함. 임의의 변화 가능한 타입일 수 있는 VARINANT 값을 사용하여 임의의 속성 설정. 콘텐츠를 특정된 텍스트에 대한 타입의 서열적 위치로서 설정. 상이한 형태의 콘텐츠가 독립적인 원래 위치를 가짐에 유의. 특정된 서열적 위치에서 콘텐츠 엘리먼트 설정. 특정된 서열적 위치에서 콘텐츠 프로세싱 명령을 설정. 계수기 내의 각각의 텍스트 스트링에 대해 <BR> 엘리먼트에 의해 분리된 텍스트 엔트리들을 생성. 'simple'로 설정된 'xml:link' 속성을 포함하는 링크 엘리먼트로 엘리먼트를 만드는 데 필요한 링크 속성들을 설정. 엘리먼트 네임 설정. 트랜잭션 내에 수행되지 않을 임시 값으로 속성을 설정.

표 16은 XML 도큐먼트들 내의 판독 전용 엘리먼트를 조작할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(212)(IGrooveReadOnly Element)를 위한 메소드들을 나타내고 있다. 판독 전용 엘리먼트는 엘리먼트들의 서브-클래스 엘리먼트이고, 다시말해 IGrooveElement를 위한 모든 메소드들이 IGrooveReadOnly Element에도 적용된다.

interface IgrooveReadOnlyElement : IGrooveElement

OpenReadOnlyParent (IGrooveReadOnlyElement** o_ppParent); OpenContenReadOnlyElement(long i_Ordinal, IgrooveReadOnlyElement** o_ppElement); OpenContentReadOnlyElementByName (BSTR i_Name, IGrooveReadOnlyElement** o_ppElement); FindContentReadOnlyElementByName (BSTR i_Name, IGrooveReadOnlyElement** o_ppElement, VARIANT_BOOL* o_pFound); OpenContentReadOnlyElementEnum (IgrooveReadOnlyElementEnum** o_ppElements); OpenContentReadOnlyElementEnumBy Name(BSTR i_Name, IgrooveReadOnlyElementEnum** o_ppElements);

판독 전용 엘리먼트 인터페이스를 엘리먼트의 부모로 리턴. 특정된 서열적 위치에서 판독 전용 엘리먼트 인터페이스를 콘텐츠 엘리먼트로 리턴. 엘리먼트의 컨텍스트 내에서, 특정된 태그 네임을 가진 엘리먼트를 탐색하고 그 판독 전용인터페이스로 리턴. 엘리먼트의 컨텍스트 내에서, 특정된 태그 네임을 가진 엘리먼트를 탐색하고 그 판독 전용인터페이스로 리턴. 엘리먼트가 탐색되지 않으면, Found는 FALSE이고 엘리먼트 레퍼런스는 리턴되지 않음. 모든 차일트 콘텐츠 엘리먼트 판독 전용 인터페이스(비회귀적)의 계수를 리턴. 모든 차일트 콘텐츠 엘리먼트 판독 전용 인터페이스(비회귀적)의 계수를 리턴. 주어진 네임을 갖는 엘리먼트들만이 리턴될 것임.

표 17은 XML 도큐먼트 내의 엘리먼트 레퍼런스들을 조작할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1214)(IGrooveElement Reference)를 나타내고 있다.

Interface IgrooveElementReference : IDispatch
OpenElement (IgrooveReadOnlyElement** o_ppElement);	판독전용 엘리먼트 인터페이스를 레퍼런스된 엘리먼트로 리턴.

스토리지 매니저의 다른 인터페이스들 내에서 사용하기 위한 인터페이스(1216) (IGrooveElementUtilBase)가 표 18에 나타나 있다. IGrooveElementUtilBase는 상용 객체들에 대한 인터페이스는 아니지만, 상용 객체들을 갖지 않은 (도 13에 도시된) 다른 서브클래스들에 대한 베이스 클래스의 역할을 하도록 의도된다. "유틸" 인터페이스들 모두는 엘리먼트와 연관된다. 스토리지 매니저 엘리먼트 util 베이스 인터페이스는 다음의 메소드들을 포함한다.

Interface IgrooveElementUtilBase : IDispatch
OpenDocument (IgrooveXMLDocument** o_ppDocument); OpenElement(IgrooveElement** o_ppElement);	XML 도큐먼트를 포함하는 인터페이스를 리턴. 엘리먼트의 인터페이스를 리턴.

표 19는 XML 도큐먼트들 내의 엘리먼트들과 연관된 실행 가능한 코드를 취급할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1218) (IGrooveBoundCode)를 나타내고 있다. 스토리지 매니저 바운드 코드 인터페이스는 다음의 메소드들을 포함한다.

Interface IGrooveBoundCode : IDispatch
SetElement(IGrooveElement* i_pElement); OpenElement(IgrooveElement** o_ppElement);	이 엘리먼트 태그와 연관된 엘리먼트 인터페이스 포인터를 설정. 이 엘리먼트 태그와 연관된 엘리먼트 인터페이스 포인터를 검색.

도 13은 상기 논의된 IGrooveElementUtilBase 베이스 클래스(1300)의 서브클래스들인 인터페이스들을 도시하고 있다. 표 20은 XML 도큐먼트들 내의 엘리먼트들 상에서 큐들을 조작할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1302)(IGrooveElementQueue)를 나타내고 있다. 엘리먼트 큐들은 "유틸" 베이스 클래스의 서브 클래스이고, 다시말해 IGrooveElementUtilBase를 위한 모든 메소드들이 IGrooveElementQueue에도 적용된다. 스토리지 매니저 엘리먼트 큐 인터페이스는 다음의 메소드들을 포함한다.

Interface IgrooveElementQueue : IGrooveElementUtilBase
Enqueue(IGrooveElement* i_pElement); Dequeue(long i_TimeoutMilliseconds, IGrooveElement**o_ppElement); DequeueEnum(long i_TimeoutMilliseconds, IGrooveElementEnum** o_ppElements); OpenEvent(IGrooveEvent** o_ppEvent);	엘리먼트들을 엔큐잉. 엘리먼트들이 큐의 도큐먼트 내에 이미 포함되어 있어야 함에 유의. 큐 내의 다음의 이용 가능한 엘리먼트를 디큐잉. 엘리먼트가 이용 가능할 때 또는 타임아웃 기간 후에만 리턴. 리턴된 IGrooveElement 포인터는 타임아웃 기간이 만료된 경우 NULL일 것임. 큐내의 이용 가능한 모든 엘리먼트들을 디큐잉. 엘리먼트가 이용 가능할 때 또는 타임아웃 기간 후에 리턴. 리턴된 IGrooveElement 포인터는 타임아웃 기간이 만료된 경우 NULL일 것임. 엘리먼트가 엔큐잉되는 것을 기다리는 데 사용될 수 있는 이벤트를 리턴.

표 21은 XML 도큐먼트들 내의 엘리먼트 레퍼런스들 상에서 큐들을 조작할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1306) (IGrooveElementReferenceQueue)를 나타내고 있다. 엘리먼트 레퍼런스 큐들은 "util" 베이스 클래스의 서브클래스이고, 다시말해 IGrooveElementUtilBase에 대한 모든 메소드들이 IGrooveElementReferenceQueue에도 적용된다. 스토리지 매니저 엘리먼트 레퍼런스 큐 인터페이스는 다음의 메소드들을 포함한다.

Interface IgrooveElementReferenceQueue : IGrooveElementUtilBase
Enqueue(IGrooveElement* i_pElement); EnqueueReference(IgrooveElement* i_pElement); Dequeue(long i_TimeoutMilliseconds, IGrooveElementReference** o_ppElementReference); DequeueEnum(long i_TimeoutMilliseconds, IgrooveElementReferenceEnum** o_ppElementReference); OpenEvent(IGrooveEvent** o_ppEvent);	엘리먼트를 엔큐잉. 엘리먼트는 큐의 도큐먼트 내에 이미 포함되어 있어야 함에 유의. 레퍼런스를 엘리먼트로 엔큐잉. 엘리먼트가 큐의 도큐먼트 내에 이미 포함되어 있어야 함에 유의. 큐 내의 다음의 이용 가능한 엘리먼트를 디큐잉. 엘리먼트가 이용 가능할 때 또는 타임아웃기간후에 리턴. 리턴된 IGroove ElementReference 포인터는 타임아웃 기간이 만료된 경우 NULL일 것임. 큐 내의 이용 가능한 엘리먼트를 디큐잉. 엘리먼트가 이용 가능할 때 또는 타임아웃기간후에 리턴. 리턴된 IGroove ElementReference 포인터는 타임아웃 기간이 만료된 경우 NULL일 것임. 엘리먼트가 엔큐잉되는 것을 "대기"하는 데 사용될 수 있는 이벤트를 리턴.

표 22는 XML 도큐먼트들 내의 엘리먼트들 상의 멀티리더 큐들로부터 엘리먼트를 제거할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1310)(IGrooveMultiReaderElementQueueReader)를 나타내고 있다. 멀티리더 엘리먼트 큐들은 "유틸" 베이스 클래스의 서브클래스이고, 다시말해 IGrooveElementUtilBase에 대한 모든 메소드들이 IGrooveMultiReaderQueueReader에도 적용된다. 스토리지 매니저 멀티리더 엘리먼트 큐 리더 인터페이스는 다음의 메소드들을 포함한다.

Interface IgrooveMultiReaderElementQueueReader : IGrooveElementUtilBase
Dequeue(long i_TimeoutMilliseconds, IGrooveElement**o_ppElement); DequeueEnum(long i_TimeoutMilliseconds, IGrooveElementEnum** o_ppElements); OpenEvent(IGrooveEvent** o_ppEvent);	큐 내의 다음의 이용 가능한 엘리먼트를 디큐잉. 엘리먼트가 이용 가능할 때 또는 타임아웃 기간 후에만 리턴. 리턴된 IGrooveElement 포인터는 타임아웃 기간이 만료된 경우 NULL일 것임. 큐 내의 모든 이용 가능한 엘리먼트를 디큐잉. 엘리먼트가 이용 가능할 때 또는 타임아웃 기간 후에만 리턴. 리턴된 IGrooveElement 포인터는 타임아웃 기간이 만료된 경우 NULL일 것임. 엘리먼트가 엔큐잉되는 것을 "대기"하는 데 사용될 수 있는 이벤트를 리턴.

표 23은 XML 도큐먼트들 내의 엘리먼트들 상에서 엘리먼트를 멀티리더 큐들에 추가할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1314)(IGrooveMultiReaderElementQueueWriter)를 나타내고 있다. 멀티리더 엘리먼트 큐들은 "유틸" 베이스 클래스의 서브클래스이고, 다시말해 IGrooveElementUtilBase에 대한 모든 메소드들은 IGrooveMultiReaderElementQueueWriter에도 적용된다. 스토리지 매니저 멀티리더 엘리먼트 큐 라이터 인터페이스는 다음의 메소드들을 포함한다.

Interface IgrooveMultiReaderElementQueueWriter : IGrooveElementUtilBase
Enqueue(IGrooveElement *i_pElement, long* o_pNumEnqueued); GetNumReaders(long* o_pNumReaders);	엘리먼트를 엔큐잉하고 이미 엔큐잉된 숫자를 리턴. 엘리먼트는 큐의 도큐먼트에 이미 포함되어야 함에 유의. 큐 상의 리더들의 수를 얻음.

표 24는 XML 도큐먼트들 내의 엘리먼트들 상에서 멀티리더 큐들에 엘리먼트 레퍼런스들을 가산할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1318)(IGrooveMultiReaderElementREferenceQueueWriter)를 나타내고 있다. 멀티리더 엘리먼트 레퍼런스 큐들은 "유틸" 베이스 클래스의 서브클래스이고, 다시말해 IGrooveElementUtilBase에 대한 모든 메소드들은 IGrooveMultiReaderElement ReferenceQueueWriter에도 적용된다. 스토리지 매니저 멀티리더 엘리먼트 레퍼런스 큐 라이터 인터페이스는 다음의 메소드들을 포함한다.

Interface IgrooveMultiReaderElementReferenceQurueWriter :
Enqueue(IGrooveElement*i_pElement, long*o_pNumEnqueued); EnqueueReference(IgrooveElement* i_pElement, long*o_pNumEnqueued); GetNumReaders(long* o_pNumReaders);	엘리먼트를 엔큐잉하고 이미 엔큐잉된 숫자를 리턴. 엘리먼트가 큐의 도큐먼트 내에 이미 포함되어 있음에 유의. 엘리먼트 레퍼런스를 엔큐잉하고 이미 엔큐잉된 숫자를 리턴. 엘리먼트가 큐의 도큐먼트 내에 이미 포함되어 있음에 유의. 큐 상에 리더들의 숫자를 얻음.

표 25는 XML 도큐먼트들 내의 엘리먼트들 상에서 멀티리더 큐들로부터 엘리먼트 레퍼런스를 제거할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1318)(IGrooveMultiReaderElementReferenceQueueReader)를 나타내고 있다. 멀티리더 엘리먼트 레퍼런스 큐들은 "유틸" 베이스 클래스의 서브클래스이고, 다시말해 IGrooveElementUtilBase에 대한 모든 메소드들은 IGrooveMultiReaderElement ReferenceQueueReader에도 적용된다. 스토리지 매니저 멀티리더 엘리먼트 레퍼런스 큐 리더 인터페이스는 다음의 메소드들을 포함한다.

Interface IgrooveMultiReaderElementReferenceQueueReader: IgrooveElementUtilBase
Dequeue(long i_TimeoutMilliseconds, IGrooveElementReference** o_ppElementReference); DequeueEnum(long i_TimeoutMilliseconds, IgrooveElementReferenceEnum** o_ppElementReferences); OpenEvent(IGrooveEvent**o_ppEvent);	큐내의 다음의 이용 가능한 엘리먼트 레퍼런스를 디큐잉. 엘리먼트가 이용 가능할 때 또는 타임아웃 기간 후에만 리턴. 리턴된 IGrooveElementReference 포인터는 타임아웃 기간이 만료된 경우 NULL일 것임. 큐내의 이용 가능한 엘리먼트 레퍼런스를 디큐잉. 엘리먼트가 이용 가능할 때 또는 타임아웃 기간 후에 리턴. 리턴된 IGrooveElementReference포인터는 타임아웃기간이 만료된 경우 NULL일 것임. 엘리먼트가 엔큐잉되는 것을 "대기"하는 데 사용될 수 있는 이벤트를 리턴.

표 26은 XML 도큐먼트들 내의 엘리먼트들 상에서 원격 절차 호출들(RPC들)을 수행할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1304)(IGrooveRPCClient)를 나타내고 있다. RPC 클라이언트들은 "유틸" 베이스 클래스의 서브클래스이고, 다시말해 IGrooveElementUtilBase에 대한 모든 메소드들이 IGrooveRPCClient에도 적용된다. 스토리지 매니저 RPC 클라이언트 인터페이스는 다음의 메소드들을 포함한다.

Interface IGrooveElementRPCClient : IGrooveElementUtilBase
DoCall(IGrooveElement*i_pInput, IGrooveElement**o_ppOutput); SendCall(IGrooveElement*i_pInput); OpenResponseQueue (IGrooveElementQueue** o_ppQueue);	입력 엘리먼트를 입력 파라미터로서 사용하고 출력 엘리먼트에서 출력 파라미터를 수신하여 RPC를 작성. 입력 엘리먼트를 입력 파라미터로서 사용하여 비동기 RPC를 작성. 응답들이 수신되는 큐를 리턴.

XML 도큐먼트들 내의 엘리먼트들 상에서 원격 절차 호출들(RPC들)을 취급하는 것이 필요한 스토리지 매니저의 클라이언트에 대한 인터페이스(1308)(IGroove RPCServerThread)가 표 27에 도시되어 있다. RPC 서버 쓰레드들은 "유틸" 베이스 클래스의 서브클래스이고, 다시말해 IGrooveElementUtilBase에 대한 모든 메소드들이 IGrooveRPCServerThread에도 적용된다. 스토리지 매니저 RPC 서버 콜백 인터페이스는 그 자신의 메소드를 갖지 않고, IGrooveElementUtilBase로부터 물려 받은 메소드들만을 갖는다. 타입을 검사하기 위한 개별적인 인터페이스로서 제공된다.

Interface IGrooveElementRPCServerThread : IGrooveElementUtilBAse
(none)

표 28은 XML 도큐먼트들 내의 엘리먼트들 상에서 원격 절차 호출들(RPC들)을 취급할 필요가 있는 스토리지 매니저의 클라이언트에 대한 인터페이스(1312)(IGrooveRPCServer)를 나타내고 있다. RPC 서버들은 "유틸" 베이스 클래스의 서브클래스이고, 다시말해 IGrooveElementUtilBase에 대한 모든 메소드들이 IGrooveRPCServer에도 적용된다. 스토리지 매니저 RPC 서버 인터페이스는 다음의 메소드들을 포함한다.

Interface IGrooveElementRPCServer : IGrooveElementUtilBase
OpenCallQueue (IGrooveElementQueue** o_ppQueue); SendResponse(IgrooveElement* i_pInput, IGrooveElement*i_pOutput, VARIANT_BOOL*o_bResult);	콜들이 수신되는 큐를 리턴. 출력 엘리먼트 내의 출력 파라미터들을 리턴하며, 콜러에 응답을 전송.

다음의 표들은 상기 인터페이스들 내에 리스트된 계수화된(enumerated) 데이터 타입에 대해 허용된 값들을 나타내고 있다. 특히, 표 29는 GrooveSerialize Type 계수화 데이터 타입에 대해 허용된 값들을 나타내고 있다.

GrooveSerialize Type
GrooveSerializeAuto GrooveSerializeMIME GrooveSerializeXML GrooveSerializeWBXML	입력 상에서, 그루브는 입력 스트림의 몇몇 바이트들을 조사함으로써 올바른 포맷을 결정할 것임. 출력 상에서,그루브는 도큐먼트의 종류 또는 엘리먼트 자료를 기초로 하여 포맷을 선택할 것임. 포맷은 RFC 2557에 정의된 MHTML임. 포맷은 XML임. 이진 도큐먼트들은 이 포맷으로 지원되지 않지만, MHTML 내의 바디 타입이 될 수 있음. 포맷은 WBXML임. 이전 도큐먼트들은 이 포맷으로 지원되지 않지만, MHTML 내의 본체 타입이 될 수 있음.

표 30은 GrooveSerializeOptions 계수화 데이터 타입에 대해 허용된 값들을 나타내고 있다.

GrooveSerializeOptions
GrooveSerializeDefault GrooveSerializeWithFormatting GrooveSerializeSortedAttrs GrooveSerializeNoFragmentWrapper GrooveSerializeNoNamespaceContraction GrooveSerializeNoProlog GrooveSerializeNoLinks GrooveSerializeNotMinimum	디폴트 일련화 옵션 사용. 부모 엘리먼트 아래에 자식 콘텐츠 엘리먼트들의 각각의 레벨을 블랭크를 이용해서 들여 써줌. 속성 네임의 오름순으로 각각의 엘리먼트에 대한 속성들을 출력. 도큐먼트 프래그먼트들(엘리먼트들)에 대한 프래그먼트 래퍼없이 출력. 완전히 확장된 엘리먼트 및 속성 네임으로 출력. XML 도큐먼트 prolog없이 출력. 링크된 도큐먼트들없이 출력. 결과 출력이 최소 크기가 되도록 필요한 만큼 로컬 프로세스 시간 소비 금지.

표 31은 GrooveParseOptions 계수화 데이터 타입에 대해 허용된 값들을 나타내고 있다.

GrooveParseOptions
GrooveParseDefault GrooveParseStripContentWhitespace GrooveParseNoFragment GrooveParseNoNamespaceExpansion GrooveParseNoLinks	디폴트 파스 옵션들을 사용. 엘리먼트 콘텐트로부터 모든 외부 여백을 제거. 프래그먼트 래퍼를 갖지 않는 프래그먼트를 파싱. 도큐먼트를 파싱하지만, 그들의 전체 분류된 형태로 네임스페이스들 확장 금지. 도큐먼트를 파싱 및 링크들을 스킵.

표 32는 GrooveContentType 계수화 데이터 타입에 대해 허용된 값들을 나타내고 있다.

GrooveContentType
GrooveContentElement GrooveContentText GrooveContentCDATASection GrooveContentProcessingInstruction GrooveContentComment	콘텐츠가 자식 엘리먼트임. 콘텐츠가 바디 텍스트임. 콘텐츠가 CDATA 섹션임. 콘텐츠가 프로세싱 명령임. 콘텐츠가 코멘트임.

표 33은 GrooveXLinkShow 계수화 데이터 타입에 대해 허용된 값들을 나타내고 있다.

GrooveXLinkShow
GrooveXLinkShowNew GrooveXLinkShowParsed GrooveXLinkShowReplace	새로운 것. 파싱된 것. 대체된 것.

표 34는 GrooveXLinkActuate 계수화 데이터 타입에 대해 허용된 값들을 나타내고 있다.

GrooveXLinkActuate
GrooveXLinkActuateUser GrooveXLinkActuateAuto	사용자. 자동.

표 35는 GrooveXLinkSerialize 계수화 데이터 타입에 대해 허용된 값들을 나타내고 있다.

GrooveXLinkSerialize
GrooveXLinkSerializeByValue GrooveXLinkSerializeByReference GrooveXLinkSerializeIgnore	값에 의함. 레퍼런스에 의함. 무시.

표 36은 GrooveMultiReaderQueueOptions 계수화 데이터 타입에 대해 허용된 값들을 나타내고 있다.

GrooveMultiReaderQueueOptions
GrooveMRQDefault GrooveMRQALLReceive GrooveMRQEnqueuelfNoReaders	디폴트 옵션 사용. 모든 리더들이 각각의 이벤트 통지수신. 엘리먼트를 수신하도록 현재 큐잉된 리더가 없다해도 엔큐잉.

스토리지 매니저의 기초 데이터 모델은 XML이다. XML은 반구조화되고, 계층화되고, 하이퍼링크된 데이터 모델이다. 많은 실세계에서의 문제점들은 이러한 복잡한 구조들로 용이하게 표현되지 않으며 테이블 형태로 보다 잘 표현된다. 예를 들어, 스프레드시트들 및 관계형 데이터베이스들은 간단한 테이블 형태의 인터페이스를 제공한다. 본 발명의 한 특징에 따르면, 표현을 간소화하기 위해, XML 구조들이 테이블 표시, 일반적으로 소위 "와플"로 맵핑된다. 이 와플은 데이터의 집합을 표현한다. 이러한 맵핑은 스토리지 매니저의 컴포넌트인 집합 매니저에 의해 수행된다.

집합은 XML 도큐먼트 타입 기술인 집합 디스크럽터에 의해 정의된다. 도큐먼트 스키마처럼, 집합 디스크럽터는 집합 데이터 그 자체에서 떨어져 저장된 특수 종류의 도큐먼트이다. 집합 데이터의 많은 소스들이 존재하지만, 집합 데이터의 주요 소스는 소프트웨어 루틴, 소위 레코드 세트 엔진이다. 사용자 명령들에 의해 구동되면, 레코드 세트 엔진은 집합에 대한 업데이트 세트를 집합 매니저로 전달한다. 이러한 업데이트들을 기초로 하여, 집합 매니저는 인덱스 구조들을 업데이트하고 통지 시스템을 통해 와플 사용자들에게 통지할 수 있다. 와플 사용자가 업데이트된 또는 새로운 집합 데이터를 필요로 할 때, 와플 사용자는 집합 매니저를 호출하여 업데이트된 데이터를 포함하는 새로운 결과 어레이를 리턴시킬 것이다. 와플 사용자는 또한 커서를 사용하여 집합 내에서 이동할 수 있다.

다음의 목록은 집합 디스크럽터 도큐먼트에 대한 XML DTD 콘텐츠를 나타내고 있다.

각각의 집합은 그것을 레퍼런스하는 데 사용되는 네임을 갖는다. 시작 속성은 어떻게 집합의 "루트"를 찾는 지를 특정한다. 레코드 루트를 갖는 집합은 레코드 세트이며, 인덱스로 시작하는 집합은 인덱스를 통해 그리고 이후에 레코드 세트를 통해 네비게이트된다. 인덱스는 색인 또는 전체 텍스트일 수 있다. 선택적 로케이션 속성은 루트 안의 어느 곳에서 시작할지를 식별하는 관련 URL이다.

레벨은 출력 계층{의} 부분의 콘텐츠를 정의한다. 레벨은 레벨 내의 열들, 레벨내의 레코드들의 정렬 또는 그룹화, 및 서브레벨의 정의로 구성된다. 레벨은 맵핑 속성을 통해 소스 레코드 스트림 내의 레코드들과 연관된다. 맵핑이 직접이라면, 레벨은 단일 소스 레코드 타입을 나타낸다. 맵핑이 평탄화된다면, 레벨은 소스 레코드 타입 및 그 레코드의 모든 자손을 포함한다. 평탄화된 맵핑은 집합 내의 유일한 레벨 또는 최하위 레벨상에서만 특정될 수 있다. 링크 속성은 링크 속성들을 갖는 레코드들이 어떻게 취급되어야 하는 지를 특정한다. 링크들이 횡단한다면, 레코드는 개별적인 레벨로서 출력될 것이다. 링크들이 삽입된다면, 소스 레코드의 자식 레코드는 그것이 소스 레코드의 일부처럼 보일 것이다.

열은 소스 필드와 출력 어레이 열 사이의 맵핑을 정의한다. 소스 속성은 소스 레코드 내의 XSLT 경로 표현이다. 결과 속성은 결과 어레이 내의 필드의 네임이다. MultiValue 및 MultiValueSeparator 속성들은 다중 소스 값들이 결과 내로 어떻게 리턴되는 지를 정의한다.

각각의 집합은 적어도 하나의 정의된 순서를 가질 수 있다. 이 순서는 정렬된 조합(collation) 또는 집합체 함수들(aggregate functions)을 가진 멀티레벨 그룹화일 수 있다.

SortColumn 엘리먼트는 SortDescription 내의 집합 특징들을 정의한다. 소스 속성은 정렬될 출력 열의 네임을 정의한다. 정렬은 오름순 또는 내림순이여야 한다. Strength 및 Decomposition 값들은 유니코드에 정의된 바와 동일한 의미를 갖는 입력 파리미터들이다.

2종류의 그룹화가 유일한 값들 및 단위들에 의해 이루어진다. 집합이 유일 값들에 의해 그룹화될 때, 동일 GroupColumn 값들을 갖는 모든 레코드들은 동일 글부 내에 함께 존재할 것이다. 그룹들 사이의 브레이크는 GroupColumn 값들의 변화시에 발생할 것이다. 집합이 유닛들에 의해 그룹화될 때, GroupUnits의 값에 의해 분해된 동일 GropuColumn 값들을 갖는 모든 레코드들은 동일 그룹 내에 함께 존재할 것이다. 예를 들어, GroupUnits가 "Day"라면, 주어진 일자에 대한 모든 레코드들은 동일 그룹에 존재할 것이다. AtGroupBreak가 특정된다면, 각각의 값 또는 유닛 브레이크 값에서의 집합체 함수의 결과를 포함하는 합성 행이 리턴될 것이다.

GroupColumn은 그룹화되는 결과 열을 식별한다.

간격은 범위를 정의하는 각각의 레코드 내의 2개의 필드를 식별한다. 시작 및 종료 열의 데이터타입들은 숫자이거나 일시여야 한다.

다음의 예는 6개의 조합 정렬들을 갖는 간단한 도큐먼트 논의 레코드 뷰에 대한 집합 디스크럽터 도큐먼트를 나타내고 있다.

다음의 예는 캘린터 형태를 위한 집합 디스크럽터를 도시하고 있다. 종래 의 예와 유사하지만, 소트 디스크럽터에 대한 작은 변화로, 집합이 일자 간격의 범위에 의해 정렬된다.

기본 스토리지 매니저로서, 집합 매니저는 객체 지향 환경에서 구현된다. 따라서, 집합 매니저 그 자체와 집합, 와플, 커서, 결과 어레이, 및 레코드 세트 엔진을 포함하는 모든 집합 컴포넌트들이 객체들로서 구현된다. 이러한 객체들, 그 인터페이스, 하부 구조, 및 집합 매니저와 인터페이스하는 데 사용되는 API가 도 14에 도시되어 있다. API는 도 15와 함께 보다 상세히 설명된다. 도 14를 참조하면, 집합 매니저는 집합 조작 API(1402)를 통해 집합에 대한 공유 억세스를 제공하지만, 클라이언트 어플리케이션들에 대한 전체 프로그래밍 모델을 가능하게 위해, 추가 통신 및 동기 동작들이 집합의 컨텍스트 내에서 제공된다. 예를 들어, 사용자는 엔진 API(1404)에 의해 레코드 세트 엔진(1412)을 제어할 수 있다. 엔진 API(1404)의 명령의 제어하에서, 레코드 세트 엔진(1412)은 집합에 대한 업데이트 세트를 상기 논의된 분산 가상 객체 시스템(1410)에 전달한다. 이러한 업데이트들을 기초로 하여, 분산 가상 객체 시스템(1410)은 인덱스 및 다른 구조들을 업데이트한다.

다른 클라이언트 컴포넌트들은 집합 매니저에 의해 관리되는 와플들과 같은 컴포넌트들 내의 변화를 할 필요가 있을 수 있다. 따라서, 집합 매니저는 클라이언트 컴포넌트들에 대한 관심 기반 통지 시스템(1406)에 인터페이스(1400)를 제공한다. 통지 시스템(1406)은 집합을 표현하는 객체들(1408) 내의 값들이 변화할 때 고나심을 등록한 클라이언트 컴포넌트 청자에 통지를 제공한다.

집합 데이터는 집합 객체들, 레코드 객체들, 와플 객체들, 커서 객체들, 및 결과 어레이 객체들(1408)을 포함하는 객체 세트에 의해 표현된다. 객체들은 집합 조작 API(1402)에 의해 직접 조작될 수 있다. 집합 관계형 객체들(1408)은 위에서 상세히 논의되었던 분산 가상 객체 시스템(1410)에 의해 실제로 구현된다.

도 15와 다음의 표들은 본 발명의 집합 매니저의 바람직한 실시예를 구현하는 데 사용되는 객체들 각각에 대한 인터페이스들의 기술을 포함하고 있다. 스토리지 매니저 구현에 있어서, 이들 객체들은 공통 객체 모델(COM)에 따라 설계되지만, 또한 다른 스타일의 인터페이스 및 객체 모델을 사용하여 구현될 수 있다.

표 37은 집합 상에서 수행되는 주요 동작들에 대한 기본 프레임워크를 캡슐화하는 집합 매니저에 대한 인터페이스(IGrooveCollectionManager)를 나타내고 있다. 집합 매니저 인터페이스는 다음의 메소드들을 포함한다.

Interface IGrooveCollectionManager : IGrooveDispatch

CreateCollection(IGrooveElement +i_pCollectionDescriptor, BSTR i_CollectionURL, BSTR i_EngineID, IGrooveCollection**o_ppCollection); DeleteCollection(IGrooveXMLDocument *i_pSourceDocument, BSTR i_CollectionURL); OpenCollection(IGrooveElement +i_pCollectionDescriptor, BSTR i_CollectionURL, BSTR i_EngineID, IGrooveCollection**o_ppCollection); OpenCollectionEnu(IGrooveXMLDocument*i_pSourceDocument, IGrooveGSTREnum **o_ppCollectionNames); ParseCollectionDescriptor(IGrooveElement*i_pCollectionElement, void* m_Levels); UpdateCollection(void*i_Updates, BSTR i_EngineID, IGrooveElement** o_ppUpdateContext);

새로운 집합 객체를 생성. 집합 디스크럽터는 GrooveCollection XML DTD에 따라 XML 내의 집합 디스크럽터를 포함해야 함. 소스도큐먼트로부터 특정된 집합 삭제. 기존의 집합 객체 오픈. 도큐먼트 내의 모든 집합의 계수 리턴 특정된 집합 디크럽터에 따라 집합 도큐먼트를 생성. 엔진 ID에 대한 집합 상에서 동작들 (GrooveCollectionUpdateOp 종류)의 요청된 시퀀스를 수행.

표 38은 집합상에서 수행되는 주요 동작들에 대한 기본 프레임워크를 캡슐화하는 집합에 대한 인터페이스(1502)(IGrooveCollection)를 나타내고 있다. 집합 인터페이스는 다음의 메소드들을 포함한다.

Interface IGrooveCollection : IGrooveDispatch
AdviseListeners(IGrooveElement *i_UpdateContext); CloseWaffle(IGrooveWaffle *i_pWaffle); Delete(void); DisableLinsteners(void); EnableListners(void); Find(BSTR i_pQuery, IGrooveCollection** o_ppQue	이 엘리먼트의 변화를 가입 청자에 통지. 집합의 청자의 리스트로부터 IGroove Waffle 인스턴스를 제거. 데이터베이스로부터 집합을 삭제. 모든 가입 청자들에 대한 이벤트 통지들을 디스에이블. 모든 가입 청자들에 대한 이벤트 통지들을 인에이블. 이벤트 통지가 디폴드로 인에이블되므로, 디스에이블 청자가 이전에 호출된 경우에만 필요함. 특정된 XSLT 질의 표현을 사용하여, 집합상에서 그것을 평가 및 새로운 집합을 결과로서 리턴.

Interface IGrooveCollection : IGrooveDispatch

GetCursor(IGrooveCollectionCursor **o_ppCursor); GetCursorPosition(double* o_pRelativePosition);

XSLT 로케이터는 다음의 형태를 가짐. Axisldentifier(NodeTestPredicate) Axisldentifier가 다음 중 하나인 경우: form-ancestors form-ancesotrs-or-self from-attributes form-children from-descendants form-descendants-or-self form-following form-following-siblings from-parent from-preceding from-preceding-siblings from-self form-source-link NodeTest 는 QName의 형식이고, 노드가 특정 네임을 가진 엘리먼트 혹은 속성인지 판단. 술어(Predicate)는 [Predicate Expr]의 형태이고 PrediccateExpr는 다음 중의 하나임: VariableReference (Expr) Literal Number FunctionCall 다중 술어는 "/"에 의해 분리됨 예를 들어: from-children(ElementName[from-attributes(AttributeName)]) 집합에 의해 현재 사용되는 커서의 카피를 리턴. 0.0(제1 행) 및 100.0(최종 행) 사이의 수치로서 커서의 상대 위치를 리턴.

Interface IGrooveCollection : IGrooveDispatch

GetEngineMappingTable(void **o_ppEngineURLs); GetExpansionMask(long *o_pMask); GetRecordCount(long* o_pRecordCount); HasOrdinalSort(BSTR* o_pSortName, VARIANT_BOOL *o_pHaveSort); HasSort(BSTR i_ColumnName, GroovecolliationOrder i_CollationOrder, long i_Level, BSTR*o_pSortName, VARIANT_BOOL*o_pHaveSort); IsEmpty(VARIANT_BOOL*o_plsEmpty); MarkAll(VARIANT_BOOL i_Read); MarkRead(double i_RecordID); MarkUnread(double i_RecordID); MoveCursor(GrooveCollecitonCursor Position i_AbsolutePositon, GrooveCollectionNavigationOp i_Navigator, long i_Distance, long *o_pDistanceMoved);

엔진 맵핑 테이블 리턴. 확장 마스크의 현재 값을 얻음. 집합 내의 레코드들의 수를 리턴. 집합이 서열적 인덱스를 가지면, 소트 네임 및 값 TRUE 값을 리턴, 그렇지 않으면 FALSE를 리턴. 조합 정렬 i_AscendingSort내의 레벨 i_Level에서 i_ColumnName에 의해 특정된 열에 대한 집합에 소트가 존재하는 지를 나타내는 불을 리턴. 소트가 존재하면 정렬 이름을 o_pSortName로 리턴. 집합이 비어 있는 지를 표시하는 불 리턴. 집합내의 모든 레코드들에 대한 레코드 리드/언리드 인디케이터를 리드 값이 되도록 설정. 마킹되는 특정레코드를 리드로서 설정. 마킹되는 특정 레코드를 언리드로 설정. 각각의 집합은 커서를 가짐. 커서는 소스 도큐먼트 내의 시작 위치를 설정하고 이후에 결과 도큐먼트를 구축하는데 사용됨. 절대 위치는 제1, 최종, 또는 현재 값을 가질 수 있음. 네비게이터는 다음의 값들을 가짐. Value Description NextAny, PriorAny 커서를 다음/이전의 소스 행으로 이동, 자식 행을 통해 내려가고 부모 행을 통해 올라감. NextPeer, PriorPeer 커서를 동일 레벨에서 다음/이전의 소스 행으로 이동, 행이 높은 레벨에 도달하면 중단.

Interface IGrooveCollection : IGrooveDispatch

MoveCursorToRecord(double i_RecordID); MoveCursorToValue(BSTR i_pQuery, double*o_pRecordID); MoveToCursor(IGrooveCollection Cursor*i_pCursor); Open(BSTR i_CollectionURL, IGrooveElement *i_pCollectionDescriptorElement, VARIANT_BOOL i_temp, VARIANT_BOOL i_Shared, VARIANT_BOOL*o_pCreated); OpenRecord(double i_RecordID, IGrooveRecord**o_ppRecord); OpenRecordID(double i_SourceRecordID, enum GrooveCollectionNavigationOp i_Relation, double* o_pTargetRecordID); OpenResultArray(long i_NumReturnRows, void *io_pResultArray);

NextParent, PriorParent 커서를 다음/이전의 부모 소스 행으로 이동, 루트 행에 도달할때까지 횡단. NextDAta, PriorData 커서를 다음/이전의 데이터 레코드를 포함하는 행으로 이동. NextUnread, PriorUnread 커서를 다음/이전의 언리드 행으로 이동. Distance는 절대위치에서 시작해서 네비게이터 이동의 디스턴스 반복까지 커서를 이동시킬 반복의 횟수를 설정함. 커서 이동은 커서가 실제로 움직인 숫자의 반복을 리턴함. 집합의 커서를 특정된 레코드에 대한 포인트로 설정. 현재의 소트 정렬을 사용하여, 입력 질의 값에 relop를 일치시키는 기준을 충족시키는 행에 커서를 둠. relop (relational operator)는 EQ, LT, LE, GT, 또는 GE일 수 있다. 질의값들은 현재의 소트 정렬의 열의 데이터 타입과 순서대로 일치하거나 손실 없는 방식으로 그 데이터 타입들로 변환되어야 함. 소트 정렬에서 정의되는 것보다 더 적은 질의값들이 특정되고 부분적으로 매치되는 결과를 낳음. 인터벌 상에서 정렬된 집합에서 처음의 질의값은 인터벌의 시작이고 두 번째 질의값은 종료 값임. 집합을 i_pCursor에 의해 특정된 위치로 이동. 그루브 스토리지 서비스 i_ServiceType 내의 I_CollectionURL에 의해 특정된 집합을 생성 또는 오픈. 집합이 처음 생성되었는지 여부를 알려주는 불(bool)을 리턴. 집합 내의 특정한 레코드로 인터페이스 포인터를 리턴. SourceRecordID의 위치로부터 시작하여, 특정된 집합 네비게이션 동작을 수행하고 결과 레코드 ID를 리턴. 집합의 확장 마스크, 현재 커서 위치, 및 현재 소트 순서를 제공하면, 다음의 디스크립션과 일치하는 결과 어레이로 NumReturnRows를 리턴.

Interface IGrooveCollection : IGrooveDispatch

NumReturnRows는 다른 데이터 행들 상에서 할당되며, 다른 합성된 헤더 및 푸터 행은 필요한대로 리턴될 수 있음에 유의. Column Name Data Type Description RowType UNIT1 ==WAFFLE_ROW_DATA if the row is a data record returned form an engine ==WAFFLE_ROW_HEADER false if the row is a synthesized header(e.g. category), ==WAFFLE_ROW_FOOTER if the row is a synthesized footer(e.g. aggtegate result) SynthKind UINT1 행이 데이터 행이라면, 값은 0임. 행이 합성 행이라면, 값은 다음중 하나임. - BreakUnique : 카테고리화 또는 정렬된 열의 값의 변화 지시. ColumnName (i) 열들 중 하나가 새로운 값을 가질 것임. - BreakUnitDay - BreakUnitWeek - BreakUnitMonth - BereakUnitYear - FuncTotal - FuncCount EngineD UINT4 행이 데이터 행이면, BSTR로서 저장된 URL의 벡터인 EngineID 테이블로 인덱싱. 행이 합성 행이라면, EngineID는 0 RecordID UINT4 행이 데이터 행이면, RecordID는 EngineID에 의해 식별되는 엔진으로부터 리턴. RecordID들은 EngineID들 내에서 유일함. 행이 합성행이라면, RecordID는 집합 내에서 유일한 숫자임. Level UINT1 이 행으로 들어오는 레벨 수. 레벨 09은 최상부 또는 최외측 레벨 RelativePosition UINT2 집합의 시작으로부터 이 행의 상대적 오프셋을 표시하는 0과 10000 사이의 수. 근사치일 수 있음. 예를 들어, 6823은 집합의 68.23%에 있는 행에 대한 값임.

Interface IGrooveCollection : IGrooveDispatch

OpenSchema(long i_Level, VARIANT_BOOL i_IncludeSystemColumns, IGrooveRecordSchema **o_ppCollectionSchema); OpenTransaction(IGrooveTransaction **o_ppTransaction); OpenWaffle(IGrooveWaffleListener 8i_pListener, IGrooveWaffle **o_ppWaffle); SetCursorPostion(double i_RelativePostion); SetExpansionMask(long i_Mask); SetRecordExpansion(double i_RecordID, VARIANT_BOOL i_Expand);

Read BOOL 행이 데이터 행이면, [account??]가 레코드를 판독하면 True. 행이 합성행이면, 리드는 축소되어도(collapsed) 항상 True임. ColumnName(i) 집합 디스크립션에 의해 정의됨. 이 행/열에 대한 데이터 값. 모든 레벨에서 정의된 열들과 같은 수의 열이 있음. 집합 내의 레코드에 대한 스키마 디스크립션에 인터페이스 포인터를 리턴. 집합 도큐먼트 상에서 트랜잭션 생성. IGrooveWaffle 인스턴스를 생성 및 이를 이벤트 청자의 집합 목록에 가산. 커서의 현재 위치를 특정 상대 위치를 갖는 행으로 설정. 이 위치는 0.0(제1 행)과 100.0(최종행) 사이의 수치임. 확장 마스크의 현재 값 설정. 이 마스크는 DWORD에 저장되지만, 첫번째 10 비트만이 사용됨. 비트가 설정되면, 지시된 레벨의 모든 데이터가 확장됨. 확장 마스크는 영구적이거나 공유되지 않음. 그 효과는 집합 객체상에만 있음. 확장 마스크의 디폴드 값은 모두 1임. 이 범위에 대한 단일 행에 대한 확장 상태를 설정. 확장이 True이면, 레코드는 확장될 것이며, 그렇지 않으면 축소될 것임. 엔진 ID가 0이면, 특정된 합성 레코드 ID에 의해 포함되는 모든 행들은 확장되거나 축소됨.

Update(BSTR i_EngineURL, GroovecollectionUpdateOp i_Operation, void* i_pUpdateRecord, IGrooveElement* io_pUpdateContext); UseSort(BSTR i_SortName, VARIANT_BOOL i_RetainCursorPosition);

집합 업데이트. i_Operation은 OP_ADD, OP_DELETE, 또는 OP_UPDATE 중 어느 하나임. 명명된 소트 오더에 집합에 대한 소트 오더를 설정. 특정된 SortName는 집합 디스크럽터 내의 정의된 소트 오더들 주 하나여야 함. i_RetainCursorPositon이 ture이고 현재 커서 위치가 데이터 레코드를 식별한다면, 현재 집합의 커서는 새로운 소트 오더에서와 동일한 레코드에 배치됨. 그렇지 않으면, 커서 위치는 새로운 소트오더 내의 제1 행에 배치됨.

표 39는 집합 내에서 "중요한" 이벤트들이 발생할 때마다 통지받기를 원하는 집합 매니저의 클라이언트에 대한 인터페이스(1504)를 나타내고 있다. 중요한 이벤트는 임의의 시간에 발생할 수 있으며, 집합 엘리먼트의 서열적 위치에서 갱신, 추가, 삭제, 리페어런팅(reparenting) 또는 변화를 포함한다. 집합 매니저 청자 인터페이스는 다음의 메소드들을 포함한다.

InterfaceIGrooveCollectionListener : IGrooveDispatch
OnRecordChange(IGrooveElement *i_pElement); OnSortChange(void);	엘리먼트내의 데이터가 갱신되거나 엘리먼트가 추가,삭제, 리페어런팅, 또는 서열적 위치로 변화되었을 때 호출. 집합에 대한 소트 정렬 변화시 호출

표 40은 집합 내의 커서를 이동시키기를 원하는 집합 매니저의 클라이언트에 대한 인터페이스(1506)(IGrooveCollectionCursor)를 나타내고 있다. 집합은 임의의 시간에 동작하는 하나 이상의 커서를 가질 수 있다. 집합 매니저 커서 인터페이스는 다음의 메소드들을 포함한다.

Interface IGrooveCollectionCursor : IGrooveDispatch

Move(GrooveCollectionCursorPosition i_AbsolutePosition, GrooveCollectionNavigationOp i_Navigator, long i_Distance, long *o_pDistanceMoved); OpenRecord(IGrooveRecord** o_ppRecord);

커서를 절대량 또는 상대량만큼 이동. 절대 위치는 처음, 최종, 또는 현재 값을 가질 수 있음. 네비게이터는 다음의 값들을 가질 수 있음. NextAny, PriorAny 커서를 다음/이전의 소스 행으로 이동, 차일트 행을 통해 아래로 그리고 부모 행을 통해 위로 이동함. NextPeer, PriroPeer 높은 레벨에서 행이 도달한다면, 커서를 동일레벨에서 다음/이전의 소스행으로 이동. NextParent, PriorParent 커서를 다음/이전 부모 소스 행으로 이동, 루트행에 도달할 때까지 이동. NextData, PriorData 커서를 데이터 레코드를 포함하는 다음/이전의 행으로 이동. NextUnread, PriorUnread 커서를 다음/이전의 언리드 행으로 이동. Distance는 절대위치에서 시작해서 네비게이터 이동의 디스턴스 반복까지 커서를 이동시킬 반복의 횟수를 설정함. 커서가 현재 설정된 레코드로 인터페이스 포인터를 리턴

다음의 표들은 상기 인터페이스들에 리스트된 계수화 데이터 타입에 대해 허용된 값들을 나타내고 있다. 특히, 표 41은 GrooveCollationOrder 계수화 데이터 타입에 대해 허용되는 값들을 나타내고 있다.

GroovecollationOrder
CollateAscending CollateDescending CollateOrdinal	데이터 값을 오름순으로 정렬. 데이터 값을 내림순으로 정렬. 서열적 위치로 정렬

표 42는 GrooveCollectionNavigationOp 계수화 데이터 타입에 대해 허용되는 값들을 나타내고 있다.

GrooveCollectionNavigationOp
NextAny PriorAny NextPeer PriorPeer NextParent PriorParent NextData PriorData NextUnread PriorUnread	커서를 다음 행으로 이동, 자식 행을 통해 아래로 부모 행을 통해 위로 이동. 이전의 소스 행으로 커서를 이동, 자식 행을 통해 아래로 부모 행을 통해 위로 이동. 커서를 동일레벨에서 다음의 소스 행으로 이동, 높은 레벨에 도달하면 중단. 커서를 동일 레벨에서 이전의 소스 행으로 이동, 높은레벨에 행이 도달하면 중단. 커서를 다음의 부모 소스 행으로 이동, 루트 행에 도달할 때까지 이동. 커서를 이전의 부모 소스 행으로 이동, 루프 행에 도달할 때까지 이동. 커서를 데이터 레코드를 포함하는 다음의 행으로 이동. 커서를 데이터 레코드를 포함하는 이전의 행으로 이동. 커서를 다음의 언리드 행으로 이동. 커서를 이전의 언리드 행으로 이동.

표 43은 GrooveCollectionCursorPosition 계수화 데이터 타입에 대해 허용되는 값들을 나타내고 있다.

GroovecollectionCursorPosition
First Last Current	집합 내의 제1 행. 집합 내의 최종 행. 집합 내의 현재 행. 이 위치는 상대적 커서 이동을 수행하는데 유용함.

표 44는 GrooveCollectionRowType 계수화 데이터 타입을 나타내고 있다.

GrooveCollectionRowType
ROW_DATA ROW_HEADER ORW_FOOTER	데이터 값들을 갖는 행. 예를 들어, 열 브레이크 값을 갖는 행 해더. 예를 들어, 브레이크 값들 및 군집된 결과를 갖는 행 푸터.

표 45는 GrooveCollectionSynthType 계수화 데이터 타입에 대해 허용되는 값들을 나타내고 있다.

GrooveCollectionSynthType
BreakUnique BreakUnitDay BreakUnitWeek BreakUnitMonth BreakUnitYear FuncTotal FuncCount	합성된 집합 행은 카테고리화 또는 소트된 열의 값의 변화를 표시함. 다른 열들 중 하나가 새로운 값을 가질 것임. 합성된 집합 행은 일 단위 변화에 대한 브레이크임. 합성된 집합 행은 주 단위 변화에 대한 브레이크임. 합성된 집합 행은 월 단위 변화에 대한 브레이크임. 합성된 집합 행은 년 단위 변화에 대한 브레이크임. 합성된 집합 행은 군집 전체 함수의 결과임. 합성된 집합 행은 군집 카운트 함수의 결과임.

표 46은 GrooveCollectionUpdateOp 계수화 데이터 타입에 대해 허용된 값들을 나타내고 있음.

GrooveCollectionUpdateOp
OP_ADD OP_DELETE OP_UPDATE OP_REPARENT OP_CHANGE_ORDINAL	집합에 레코드를 가산. 집합으로부터 레코드를 삭제. 집합내에 이미 존재하는 레코드 내의 특정 필드들의 값들을 변화. 그 레코드의 부모를 변화. 집합 내의 레코드의 서열적 위치를 변화.

표 47은 GrooveCollectionWaffleSystem 계수화 데이터 타입을 나타내고 있음.

GrooveCollectionWaffleSystemColumns

WAFFLE_ROWTYPE_COLUMN WAFFLE_SYNTHKIND_COLUMN WAFFLE_RECORDID_COLUMN WAFFLE_PARENT_RECORD_COLUMN WAFFLE_LEVEL_COLUMN WAFFLE_RELPOS_COLUMN WAFFLE_READ_COLUMN WAFFLE_EXPANDED_COLUMN WAFFLE_HASCHILDREN_COLUMN

GrooveCollectinRowType에 대한 값들중 하나. 데이터 행이 아니라면, GrooveCollection SynthType 내의 값들 중 하나. 레코드에 대한 유일한 식별자. 레코드 ID가 집합 내에 유일해야 하지만, 다른 범위 내에서는 유일하지 않아도 됨. 집합 내의 레코드의 레코드ID를 포함하는 부모 레코드에 대한 레퍼런스. 부모 레코드ID 내의 레코드 레퍼런스가 삭제되면, 레코드는 집합으로부터 삭제될 것임. 계층의 루트 레벨로부터의 진입 레벨의 수. 루트 레벨은 0임. 0.0(제1행)과 100.0(최종행) 사이의 수. 레코드를 판독하는 리스트. 이 필드가 존재하지 않으면, 레코드를 리드하는 사용자가 없음. 행이 축소 또는 완전히 확장되는 지에 대한 불리언 인디케이터. 행이 자식들을 갖는 지에 대한 불리언 인디케이터.

표 48은 GroovecollectionRecordID 계수화 데이터 타입에 대해 허용된 값들 을 나타내고 있다.

GrooveCollectionRecordID
NULL_RECORD_ID	특정 널 레코드 ID에 대한 예약된 값.

표 49는 GrooveSortOrder 계수화 데이터 타입에 대해 허용된 값을 나타낸다.

GrooveSortOrder
Ascending Descending	데이터 값을 오름순으로 대조. 데이터 값을 내림순으로 대조.

상술한 실시예의 소프트웨어 구현은 컴퓨터 판독 가능한 매체, 예를 들어, 디스켓, CD-ROM, ROM 메모리, 또는 고정 디스크과 같은 컴퓨터 판독 가능한 유형 매체, 또는 모뎀이나 매체에 대한 다른 인터페이스 장치를 통해 컴퓨터 시스템에 전송될 수 있는 일련의 컴퓨터 명령을 포함할 수 있다. 이 매체는 제한하는 것은 아니지만 광학 또는 아날로그 통신 라인을 포함하는 유형의 매체이거나, 제한하는 것은 아니지만 마이크로파, 적외선, 또는 다른 전송 기술을 포함하는 무선 기술로 구현될 수 있다. 인터넷일 수도 있다. 일련의 컴퓨터 명령의 시리즈는 본 발명과 관련해 본 명세서에 이미 기술된 기능들 모두 또는 일부를 구현한다. 본 기술 분야에 숙련된 자라면 이러한 컴퓨터 명령들이 다수의 컴퓨터 구조 또는 운영 체제에 사용하기 위해 다수의 프로그래밍 언어로 쓰여질 수 있다는 것을 인식할 것이다. 또한, 이러한 명령들은 제한하는 것은 아니지만 반도체, 자기, 광학 또는 다른 메모리 장치를 포함하는 현재 또는 미래의 임의의 메모리 기술을 사용하여 저장될 수 있거나, 제한하는 것은 아니지만 광학, 적외선, 마이크로파, 또는 다른 전송 기술을 포함하는 현재 또는 미래의 임의의 통신 기술을 사용하여 전송될 수 있다. 이러한 컴퓨터 프로그램 제품은 인쇄된 도큐먼트나 작게 포장된 소프트웨어 같은 전자 도큐먼트를 동반한 이동 가능 매체로 배포되거나, 시스템 롬이나 고정 디스크 같은 컴퓨터 시스템으로 미리 로드되거나, 또는 인터넷 또는 월드 와이드 웹 같은 네트워크 상의 서버나 전자 게시판으로부터 배포되도록 기획되었다.

본 발명의 실시예가 개시되었지만, 본 기술분야에 숙련된 자라면 본 발명의 범위로부터 벗어나지 않으면서 본 발명의 장점들 중 몇몇을 달성하는 다양한 변경 및 수정이 이루어질 수 있다는 것을 인식할 것이다. 예를 들어, 설명이 특정한 하드웨어 시스템 및 운영 체제에 대에 이루어졌지만, 다른 하드웨어 및 운영 체제 소프트웨어가 설명된 것과 동일한 방식으로 사용될 수 있다는 것을 당업자라면 쉽게 인식할 것이다. 본 발명의 개념에 대한 다른 수정 뿐만 아니라 특정한 기능을 달성하는 데 사용된 특정한 명령들은 첨부된 특허청구범위에 포함될 것이다.

Claims (82)

1. 삭제
2. 삭제
3. 삭제
4. 삭제
5. 삭제
6. 삭제
7. 삭제
8. 삭제
9. 삭제
10. 삭제
11. 삭제
12. 삭제
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 메모리 내에서 XML-컴플라이언트 도큐먼트를 표현 및 관리하기 위한 장치에 있어서, 상기 XML-컴플라이언트 도큐먼트는 상기 메모리 내에 제1 어드레스 공간을 갖는 제1 프로세스 및 상기 메모리 내에 제2 어드레스 공간을 갖는 제2 프로세스에 의해 동시에 업데이트되며, 상기 장치는,

    상기 제1 어드레스 공간 내의 클래스 코드로부터, 상기 제1 어드레스 공간으로 매핑(mapping)되는 영역에 저장되고 상기 XML-컴플라이언트 도큐먼트의 일부를 표현하는 제1 데이터를 포함하는 적어도 하나의 도큐먼트 객체(object)를 구성하는 상기 제1 프로세스에 의해 제어되는 제1 스토리지 매니저;

    상기 제2 어드레스 공간 내의 클래스 코드로부터, 상기 제1 데이터가 저장된 영역과 동일한 영역이지만 상기 제2 어드레스 공간으로 매핑되는 영역에 저장되고 상기 XML-컴플라이언트 도큐먼트의 일부를 표현하는 제2 데이터를 포함하는 적어도 하나의 도큐먼트 객체를 구성하는 상기 제2 프로세스에 의해 제어되는 제2 스토리지 매니저; 및

    상기 제1 프로세스가 상기 제1 어드레스 공간 내의 영역 데이터(region data)를 변경 중일 때 상기 영역 데이터를 락(lock)하는 동기 메카니즘(synchronization mechanism)

    을 포함하는 장치.
21. 제20항에 있어서, 상기 제2 프로세스는 상기 제2 어드레스 공간이 상기 영역 데이터의 가장 최근 카피를 갖고 있지 않은 경우 상기 제1 어드레스 공간으로부터 상기 영역 데이터의 카피를 요청하기 위한 메카니즘을 포함하는 장치.
22. 삭제
23. 제20항에 있어서, 상기 제2 프로세스가 상기 제2 어드레스 공간 내의 상기 영역 데이터를 변경 중일 때 상기 제2 프로세스는 상기 동기 메카니즘이 상기 영역 데이터를 락시킬 것을 요청하기 위한 메소드들을 포함하는 장치.
24. 제20항에 있어서, 상기 제1 프로세스는 상기 영역에 대해 판독 및 기입 동작들을 수행할 수 있으며 상기 장치는 복수의 상기 판독 및 기입 동작들을 트랜잭션으로 그룹화하기 위한 메카니즘을 더 포함하는 장치.
25. 제24항에 있어서, 상기 제1 프로세스는 트랜잭션 내의 모든 판독 및 기입 동작들의 프로세싱 동안에 상기 동기 메카니즘이 상기 영역 데이터를 락시킬 것을 요청하기 위한 메소드들을 포함하는 장치.
26. 제25항에 있어서, 트랜잭션 내의 모든 판독 및 기입 동작들의 프로세싱 동안에 영구적 데이터베이스에 복구 로그 엔트리들을 주기적으로 기입하는 로깅 시스템을 더 포함하는 장치.
27. 제20항에 있어서, 상기 제1 프로세스는 불휘발성 저장 장치(non-volatile store) 내에 상기 영역 데이터의 카피를 저장하기 위한 스토리지 메카니즘을 포함하는 장치.
28. 제27항에 있어서, 상기 불휘발성 저장 장치는 객체 저장 장치를 포함하는 장치.
29. 제27항에 있어서, 상기 불휘발성 저장 장치는 파일 시스템을 포함하는 장치.
30. 제20항에 있어서, 상기 동기 메카니즘은 분산(distributed) 메모리 시스템을 포함하는 장치.
31. 제20항에 있어서, 상기 제1 어드레스 공간 및 제2 어드레스 공간 모두는 제1 및 제2 도큐먼트 객체들을 조작하기 위한 등가 프로그램 코드를 포함하는 장치.
32. 제20항에 있어서, 상기 제1 및 제2 스토리지 매니저는 상기 제1 및 제2 프로세스들을 동기시키는 데 사용되는 크로스-프로세스 동기 객체를 각각 구성하는 장치.
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제
41. 삭제
42. 삭제
43. 삭제
44. 삭제
45. 삭제
46. 삭제
47. 삭제
48. 삭제
49. 삭제
50. 삭제
51. 삭제
52. 삭제
53. 삭제
54. 삭제
55. 삭제
56. 삭제
57. 메모리 내에서 XML-컴플라이언트 도큐먼트를 표현 및 관리하기 위한 방법에 있어서, 상기 XML-컴플라이언트 도큐먼트는 상기 메모리 내에 제1 어드레스 공간을 갖는 제1 프로세스 및 상기 메모리 내에 제2 어드레스 공간을 갖는 제2 프로세스에 의해 동시에 업데이트되며, 상기 방법은,

    (a) 상기 제1 프로세스에 의해 제어되는 제1 스토리지 매니저를 사용하여, 상기 제1 어드레스 공간 내의 클래스 코드로부터, 상기 제1 어드레스 공간으로 매핑되는 영역 내에 저장되고 상기 XML-컴플라이언트 도큐먼트의 일부를 표현하는 제1 데이터를 포함하는 적어도 하나의 도큐먼트 객체를 구성하는 단계;

    (b) 제2 프로세스에 의해 제어되는 제2 스토리지 매니저를 사용하여, 상기 제2 어드레스 공간 내의 클래스 코드로부터, 상기 제1 데이터가 저장된 영역과 동일한 영역이지만 상기 제2 어드레스 공간으로 매핑되는 영역에 저장되고 상기 XML-컴플라이언트 도큐먼트의 일부를 표현하는 제2 데이터를 포함하는 적어도 하나의 도큐먼트 객체를 구성하는 단계; 및

    (c) 상기 제1 프로세스가 상기 제1 어드레스 공간 내의 영역 데이터를 변경 중일 때 상기 영역 데이터를 락하는 단계

    를 포함하는 방법.
58. 제57항에 있어서, 상기 단계 (c)는 상기 제2 어드레스 공간이 상기 영역 데이터의 가장 최신의 카피를 갖고 있지 않은 경우 상기 제1 어드레스 공간으로부터 상기 영역 데이터의 카피를 요청하는 단계를 포함하는 방법.
59. 삭제
60. 제57항에 있어서, 상기 단계 (c)는 상기 제2 프로세스가 상기 제2 어드레스 공간 내의 상기 영역 데이터를 변경 중일 때 상기 영역 데이터를 락시키는 단계를 포함하는 방법.
61. 제57항에 있어서, 상기 제1 프로세스는 상기 영역에 대해 판독 및 기입 동작들을 수행할 수 있으며 상기 방법은 (d) 복수의 상기 판독 및 기입 동작들을 트랜잭션으로 그룹화하는 단계를 더 포함하는 방법.
62. 제61항에 있어서, 상기 단계 (c)는 트랜잭션 내의 모든 판독 및 기입 동작들의 프로세싱 동안에 상기 영역 데이터를 락시키는 단계를 포함하는 방법.
63. 제62항에 있어서, 상기 단계 (c)는 트랜잭션 내의 모든 판독 및 기입 동작들의 프로세싱 동안에 복구 로그 엔트리들을 영구적 데이터베이스에 주기적으로 기입하는 단계를 더 포함하는 방법.
64. 제57항에 있어서, (e) 상기 제1 프로세스의 제어를 받아, 불휘발성 저장 장치 내에 상기 영역 데이터의 카피를 저장하는 단계를 더 포함하는 방법.
65. 제64항에 있어서, 상기 불휘발성 저장 장치는 객체 저장 장치를 포함하는 방 법.
66. 제64항에 있어서, 상기 불휘발성 저장 장치는 파일 시스템을 포함하는 방법.
67. 제57항에 있어서, 상기 단계 (c)는 분산 메모리 시스템에 의해 수행되는 방법.
68. 제57항에 있어서, (f) 상기 제1 및 제2 어드레스 공간들 모두 내에서 등가의 프로그램 코드를 갖는 제1 및 제2 도큐먼트 객체들을 조작하는 단계를 더 포함하는 방법.
69. 제57항에 있어서, (g) 상기 제1 및 제2 프로세스들을 동기시키는 데 사용되는 크로스-프로세스(cross-process) 동기 객체를 생성하는 단계를 더 포함하는 방법.
70. 삭제
71. 삭제
72. 삭제
73. 삭제
74. 삭제
75. 삭제
76. 삭제
77. 메모리 내에서 XML-컴플라이언트 도큐먼트를 표현 및 관리하기 위한 컴퓨터 프로그램 제품에 있어서, 상기 XML-컴플라이언트 도큐먼트는 상기 메모리 내의 제1 어드레스 공간을 갖는 제1 프로세스 및 상기 메모리 내의 제2 어드레스 공간을 갖는 제2 프로세스에 의해 동시에 업데이트되며, 상기 컴퓨터 프로그램 제품은, 컴퓨터 판독가능한 프로그램 코드를 갖는 컴퓨터 사용가능한 매체를 포함하며,

    상기 제1 프로세스에 의해 제어되는 제1 스토리지 매니저를 사용하여, 상기 제1 어드레스 공간 내의 클래스 코드로부터, 상기 제1 어드레스 공간으로 매핑되는 영역에 저장되고 상기 제1 어드레스 공간에 저장된 상기 XML-컴플라이언트 도큐먼트의 일부를 표현하는 제1 데이터를 포함하는 적어도 하나의 도큐먼트 객체를 생성하기 위한 프로그램 코드;

    상기 제2 프로세스에 의해 제어되는 제2 스토리지 매니저를 사용하여, 상기 제1 어드레스 공간 내의 상기 클래스 코드와 동일한 상기 제2 어드레스 공간 내의 클래스 코드로부터, 상기 제1 데이터가 저장된 영역과 동일한 영역이지만 상기 제2 어드레스 공간으로 매핑되는 영역에 저장되고 상기 제2 어드레스 공간에 저장된 상기 XML-컴플라이언트 도큐먼트의 일부를 표현하는 제2 데이터를 포함하는 적어도 하나의 도큐먼트 객체를 생성하기 위한 프로그램 코드; 및

    상기 제1 프로세스가 상기 제1 어드레스 공간 내의 영역 데이터를 변경 중일 때 상기 영역 데이터를 락(lock)하기 위한 프로그램 코드

    를 포함하는 컴퓨터 프로그램 제품.
78. 삭제
79. 삭제
80. 삭제
81. 메모리 내에서 XML-컴플라이언트 도큐먼트를 표현 및 관리하기 위해 반송파 내에 구현된 컴퓨터 데이터 신호를 갖는 메모리 장치에 있어서, 상기 XML-컴플라이언트 도큐먼트는 상기 메모리 내에 제1 어드레스 공간을 갖는 제1 프로세스 및 상기 메모리 내에 제2 어드레스 공간을 갖는 제2 프로세스에 의해 동시에 업데이트되며, 상기 컴퓨터 데이터 신호는,

    상기 제1 프로세스에 의해 제어되는 제1 스토리지 매니저를 사용하여, 상기 제1 어드레스 공간 내의 클래스 코드로부터, 상기 제1 어드레스 공간으로 매핑되는 영역에 저장되고 상기 제1 어드레스 공간에 저장된 상기 XML-컴플라이언트 도큐먼트의 일부를 표현하는 제1 데이터를 포함하는 적어도 하나의 도큐먼트 객체를 생성하기 위한 프로그램 코드;

    상기 제2 프로세스에 의해 제어되는 제2 스토리지 매니저를 사용하여, 상기 제1 어드레스 공간 내의 상기 클래스 코드와 동일한 상기 제2 어드레스 공간 내의 클래스 코드로부터, 상기 제1 데이터가 저장된 영역과 동일한 영역이지만 상기 제2 어드레스 공간으로 매핑되는 영역에 저장되고 상기 제2 어드레스 공간에 저장된 상기 XML-컴플라이언트 도큐먼트의 일부를 표현하는 제2 데이터를 포함하는 적어도 하나의 도큐먼트 객체를 생성하기 위한 프로그램 코드; 및

    상기 제1 프로세스가 상기 제1 어드레스 공간 내의 영역 데이터를 변경 중일 때 상기 영역 데이터를 락(lock)하기 위한 프로그램 코드

    를 포함하는 컴퓨터 데이터 신호를 갖는 메모리 장치.
82. 삭제

Images