KR20050000352A

KR20050000352A - 공통 쿼리 런타임 시스템 및 애플리케이션 프로그래밍인터페이스

Info

Publication number: KR20050000352A
Application number: KR1020040047273A
Authority: KR
Inventors: 데사이아팬에이.; 퍼셀마크더블유.; 킴벌앤드류이.; 브런디지마이클엘.; 듀비네츠세르게이; 플레이저토드에프.
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-06-23
Filing date: 2004-06-23
Publication date: 2005-01-03
Also published as: EP1492033A3; CN100498768C; CN1573759A; US20040260691A1; EP1492033A2; JP2005018777A; US7383255B2

Abstract

쿼리 런타임 아키텍쳐와 이 아키텍쳐에 적합한 예시적인 애플리케이션 프로그래밍 인터페이스가 제시된다. 이 아키텍쳐는 하나 이상의 XML 쿼리들과 뷰들을 입력하고 이 쿼리들이 번역될 수 있도록 하는데, 이 쿼리들과 뷰들은 상이한 데이타 모델들의 다수의 데이타 소스들 상에서 구동된다. 이 아키텍쳐는 입력 쿼리들과 뷰들을 각 쿼리나 뷰의 의미를 표현하는 중간 언어 표현으로 변환시키는 프론트엔드 컴파일러를 포함한다. 이 아키텍쳐는 그 다음 이 중간 언어 표현을 조회되기를 원하는 데이타 소스들과 호환가능한 타겟 언어들로 백엔드 컴파일링하도록 한다. 이 아키텍쳐는 또한 이러한 타겟 컴파일링의 실행이 이 쿼리들에 필요한 데이타를 추출하도록 한다. 본 발명은 또한 쿼리 런타임 시스템을 위한 예시적인 애플리케이션 프로그래밍 인터페이스를 개시한다.

Description

공통 쿼리 런타임 시스템 및 애플리케이션 프로그래밍 인터페이스{COMMON QUERY RUNTIME SYSTEM AND APPLICATION PROGRAMMING INTERFACE}

본 발명은 일반적으로는 데이타 소스를 조회(querying)하는 소프트웨어의 필드에 관련된 것이고, 보다 구체적으로는 XML 중간 언어(XML intermediate language)를 이용하여 하나 이상의 데이타 소스를 조회하는 소프트웨어의 필드에 관한 것이다.

eXtensible Markup Language(XML)는 W3C(World Wide Web Consortium)에서 지원되는 인간이 판독할 수 있는 태그를 가지고 데이타를 마크업(mark up)하기 위한 일반적인 구문(syntax)을 제공하는 문서 포맷팅을 위한 표준이다(http://www.w3c.org/tr). XML은 잘 정의된 포맷으로 문서의 컨텐츠를 쉽게 정의할 수 있지만, 그 구조가 표준 텍스트 문서의 구조와 일치하지 않거나 기타 XML 호환가능하지 않은 특성들 때문에 그렇게 쉽게 기술될 수 없는 다른 데이타 소스들이 있다. 이러한 데이타 소스의 예로 스프레드시트나 관계형(relational) 데이타베이스가 있다.

다양한 데이타 프로그래밍 모델을 갖는 데이타 소스들 상에서 XML과 같은 검색을 검색을 수행하는 시도를 가상 XML(virtual XML)이라고 한다. 이 용어는 일반적으로 가상 XML 관점에서 조회를 하는 것을 포함하는 것으로 해석된다. 가상 XML은 데이타 액세스 프로그래밍 모델들에 걸쳐 일관성을 확립하고 사용자들이 실제 저장 형식 대신 사용자들이 생각하는 방식으로 데이타를 가지고 작업하도록 하는 개념이다. 가상 XML 데이타를 조회를 하는 이 개념은 데이타가 실제로 XML로 변환되지 않고 XML인 것 처럼 데이타를 취급하는 것을 포함한다. 이 개념의 한가지 이점은 XML 인코딩의 오버헤드를 최소한으로 유지한다는 것이다. 가상 XML 시나리오가 데이타 소스가 XML 쿼리인 것처럼 비XML 데이타 소스를 조회하기 위한 쿼리 언어를 이용할 수 있다는 장점을 갖는 다면 바람직하다. 또한 실제 데이타와 고충실도(high fidelity)로 가상 XML 표현 간에 매핑을 하는 것도 바람직하다.

가상 XML을 구현하기 위한 수많은 시도들이 있다. 한가지 문제점은 효율이다. 어떤 사람은 단순히 데이타 소스를 예컨대, XML Reader와 같은 가상 XML 인터페이스로 노출시킨 다음, 그에 대해 예를 들어, XML DOM(Document Object Model)과 같은 기존의 XML 쿼리 구현 방법을 가지고 조회를 할 수 있다. 그러나, 모든 작업은 데이타 소스 자체에 의해 수행되는 것이 아니라, XML 쿼리 엔진에서 일어난다. 데이타 소스 자체와, 관련 데이타 관리 시스템은, 특별히 고안된 언어로 데이타의 조회를 수행함에 있어서 상이한 데이타 모델을 가지고 있는 외부의 쿼리 시스템보다 효과적인 것으로 추정된다.

이러한 측면은 가상 XML 쿼리를 수행함에 있어서 다른 문제를 일으키는데, XML 데이타 모델이 하부의 데이타 모델과 그러한 형식의 시스템과 항상 잘 정렬되는 것은 아니라는 것이다. 하부의 데이타 소스의 모든 형식들을 XML 형식으로 매핑할 수 있으나, 이 과정은 충실도를 상실하고 효과적이지도 않다. 또한, 한 시스템 내의 형식들은 다른 시스템에서 명백한 등가물을 갖지 않는다. 예를 들어, XML에서 화상과 같은 이진 데이타를 표현하는 데에는 힘든 XML 문자 세트 변환(예컨대, 베이즈64-인코딩)을 요구한다.

가상 XML를 조회하기 위한 이전의 방법들은 두개의 상이한 데이타 구조들: 질의를 위한 것과 매핑을 위한 것을 구성하고, 그 다음 이들을 직렬고 가로질러 가상 XML 뷰를 실현시키지 않고 원래의 데이타 소스들에 대한 직접적이고 효과적인 쿼리를 생성함으로써 이 문제에 접근했다. 이 방법은 초기에는 잘 기능했지만, 쿼리와 매핑 언어가 복잡해짐에 따라 점차 개발이 어려워졌다. 쿼리나 매핑에 있어서 개념은 흔히 직접 타겟 데이타 모델로 번역을 하는 것이 아니며, 복합 XML 뷰들을 갖는 복잡한 쿼리들을 구성하는 것은 충분한 의미론적 리졸브 및 재기록을 요구한다.

또한, 하나의 언어로 된 쿼리들을 쿼리 표현 또는 많은 데이타 소스들 상의 쿼리 결과로 변환하는 것을 지원할 수 있는 시스템 아키텍쳐는 N 개의 경로들을 M회 구현하는 힘든 과정을 요구하는데, 여기서 M은 입력 옵션의 수이고 N은 출력 옵션의 수이다. 표준 아키텍쳐를 사용하면 이러한 변형 컴파일러는 많아질 수 있다.

따라서 XML 쿼리들과 XML과 비XML 데이타 소스들 상에서 XML 쿼리들과 뷰들에 대해 가상 XML을 구현하기 위한 통합적인 표현과 단일 시스템 아키텍쳐가 필요하다. 본 발명은 상기한 필요성을 논의하고 본 발명의 시스템의 사용자를 위한 통합적인 표현과 애플리케이션 프로그래밍 인터페이스를 이용하는 아키텍쳐 모두를 가지고 이 문제들을 해결한다.

도 1은 본 발명의 특징들이 실시되는 예시적인 컴퓨팅 환경을 도시하는 블럭도이다.

도 2는 본 발명의 특징들이 실시되는 블럭도 아키텍쳐를 도시한다.

도 3은 본 발명의 특징들에 적용가능한 흐름도를 도시한다.

(도면의 주요부분에 대한 부호의 설명)

210: XML 언어 컴파일러

215: 중간 언어 표현

220: 타겟 생성기

230: 실행 엔진

240: 데이타 소스(들)

250: 쿼리 결과

입력을 수신하기 위한 입력 장치, 이 입력 쿼리의 의미론적 의미를 생성하기 위한 중간 언어 컴파일러, XML 중간 언어 표현을 타켓 쿼리를 형성하는 타켓 언어로 변환하는 타겟 생성기(또는 타겟 언어 컴파일러), 하나 이상의 데이타 소스, 및 실행 엔진을 포함하는, 쿼리 결과들을 생성하는 입력 쿼리들을 컴파일 및 실행하기위한 시스템이 제시된다. 이 실행 엔진은 입력 쿼리가 데이타 소스(들) 사이에서 실행되도록 한다. 이 실행 엔진은 XML 중간 언어를 직접 실행하거나 그 쿼리를 실행하기 전에 먼저 XML 중간 언어를 타겟 언어로 변환할 수 있다. 이 입력 쿼리는 임의의 XML 쿼리나 뷰로부터 나올 수 있으며 타겟 언어는 데이타 소스를 조회를 할 수 있는 임의의 쿼리 언어가 될 수 있다. 데이타 소스는 관계형 또는 비관계형(예컨대, 계층적) 데이타일 수 있고 시스템은 다수의 데이타 소스를 조회를 할 수 있다.

애플리케이션 프로그래밍 언어의 기능을 정의하는, 애플리케이션과 통신하기 위한 방법이 기술된다. 애플리케이션은 하나 이상의 입력 쿼리들을 XML 중간 언어 표현으로 변환하기 위한 하나 이상의 컴파일 파라미터와 커맨드를 설정하기 위한 하나 이상의 콜을 이 쿼리 시스템에 보낼 수 있다. 애플리케이션은 추가로 이 시스템에 XML 중간 언어 표현을 실행가능한 쿼리로 변환하기 위한 하나 이상의 콜을 보낼 수 있다. 이 시스템은 애플리케이션에 예컨대, 이벤트 상태, 진행 상태, 중간 결과, 최종 결과, 에러 메세지, 경고 및 도움말 메세지들을 송신할 수 있다.

본 발명의 추가의 특직들과 장점들은 첨부 도면을 참조로 진행하는 예시적인 실시예의 이하의 상세한 설명으로부터 명백해 질 것이다.

이하의 바람직한 실시예들의 상세한 설명 뿐만 아니라 이상의 요약은 첨부 도면과 함께 읽을 때 보다 잘 이해될 것이다. 발명을 설명하기 위해, 발명의 예시적인 구성이 도면에 도시되었지만, 본 발명은 이 구체적인 방법과 개시된 장치에 한정되는 것이 아니다.

<개관>

본 발명은 다수의 쿼리 소스로부터의 다수의 형태의 데이타 소스를 조회를 하는 문제를 다룬다. 가상 XML 데이타 소스를 조회하는 문제를 해결하는 하나의 해결책은 통합적인 중간 언어를 사용하는 것일 수 있다. 본 발명의 XML 중간 언어는 쿼리의 의미를 명시적으로 나타낸다. XML 중간 언어는 쿼리 중간 언어(QIL)라고 한다.

QIL은 "쿼리/뷰 조합"이라고 하는 문제를 다룬다. 예를 들어, XML 쿼리가 XML, XML 가상, 또는 다른 데이타이든, 데이타의 가상 XML 뷰 상에서 수행된다고 가정한다. 한가지 방법은 데이타 소스를 XML로 가시화하는 것이나, 이는 매우 비효과적이고 시스템에 가능한 것보다 많은 노력을 필요로 할 것이다. 이 뷰를 가상화하기 위한 다른 방법은 쿼리를 이 가상 뷰와 합성하고, 그 결과를 원래 데이타 상에서의 동작들로 번역하는 것이다. 사용자는 논리적 XML 데이타 모델 상에서 XML 쿼리를 보지만, 이 실시예는 어떤 쿼리 시스템을 제공하든지 간에 그것을 사용하여 원래의 데이타 포맷을 조회한다. 이 방법은 SQL(structured query language) 뷰에서 구조화된 SQL 쿼리들을 위한 관계형 데이타베이스에서 사용되고, 과거에는 XML 뷰에서 XML 쿼리들을 실행하는데 사용되기도 하였다. 그러나, QIL과 같은 XML 중간 언어를 사용하여, 원래의 잠재적으로 복합 뷰는 그 쿼리를 실행하기 전에 보다 작은 원자적 쿼리로 분해될 수 있다. 이러한 방식으로, 복합 뷰를 상의 조회는 쿼리 조회 더하기 보다 단순한 뷰가 된다. 쿼리 합성은 이것을 단지 보다 단순한 뷰를 조회하는 것으로 바꾸어, 문제를 단순화한다. 다른 말로, XML 뷰 자체가 단순히 쿼리가 된다.

XML 중간 언어 QIL은 (1) XML 쿼리와 XML 뷰 모두의 일정한 표현을 제공하여, 쿼리/뷰 합성 문제를 매우 단순화하고 (2) 모든 뷰들은 "가상 XML"로 취급하여 시스템의 인터페이스를 매우 단순화시킨다. 가능한 모든 언어와 데이타 모델에 대해 하나의 API를 갖는 대신, 모든 API는 공통의 데이타 모델, XML 중간 언어 QIL의 오퍼레이터를 공유할 수 있다.

XML 중간 언어, QIL은 또한 공지의 컴파일러 문제를 해결한다. 보통, 언어를 가지고 컴파일러는 N개의 백셍드 타겟 머신에서 M개의 프론터엔드 언어를 구현할 필요가 있다(여기서 M과 N은 정수). 각 쌍의 조합이 구현되면, M 회의 N 개의 컴파일러 실행이 원하는 조합을 커버하는데 필요하다. 그러나, 공통의 중간 표현을 도입함으로서 이 두개가 분리되면, 컴파일러의 복잡성은 M 더하기 N으로 줄어든다.

본 발명은 QIL을 이용한 쿼리 런타임 시스템을 위한 아키텍쳐 및 하나 이상의 애플리케이션 프로그램에 의해 이 시스템의 사용을 가능하게 하는 예시적인 애플리케이션 프로그래밍 인터페이스 모두를 개시한다.

<예시적인 컴퓨팅 장치>

도 1과 이하의 논의는 본 발명이 구현되기에 적절한 컴퓨팅 환경의 간단한 일반적인 설명을 제공하기 위한 것이다. 그러나, 핸드핼드, 포터블 및 다른 장치와 모든 종류의 컴퓨팅 오브젝트들이 본 발명과 관련하여 사용되도록 고안된다는 것을 이해해야 한다. 따라서, 이하에는 범용 컴퓨터가 기술되었지만, 이는 하나의예이고, 본 발명은 네트워크/버스 상호운영 및 상호작용을 갖는 클라이언트와 같은 다른 컴퓨팅 장리로도 구현될 수 있다. 따라서, 본 발명은 클라이언트 자원이 매우 조금 또는 최소한으로 구현된, 예컨대, 클라이언트 장치가 단지 네트워크/버스에 대한 인터페이스로만 기능하는, 어플라이언스에 위치한 오브젝트 또는 다른 컴퓨팅 장치와 오브젝트와 같은 네트워킹된 환경 등의 네트워킹된 호스트 서비스 환경에서 실시될 수 있다. 본질적으로, 데이타가 저장되거나 데이타가 검색될 수 있는 어떤 곳도 본 발명에 따른 동작에 바람직하거나 적합한 환경이 될 수 있다.

필수적인 것은 아니지만, 본 발명은, 장치나 오브젝트를 위한 서비스 개발자에 의한 사용을 위해, 및/또는 본 발명에 따라 작동하는 애플리케이션 소프트웨어 내에 포함된, 운영 체계를 통해 구현될 수 있다. 클라이언트 워크스테이션, 서버 또는 기타의 장치와 같은 하나 이상의 컴퓨터들에 의해 실행되는, 프로그램 모듈과 같은, 컴퓨터 실행가능한 명령들의 일반적인 컨텍스트로 소프트웨어가 기술될 수 있다. 일반적으로, 프로그램 모듈은 루틴, 프로그램, 오브젝트, 컴포넌트, 데이타 구조 등 특정 추상 데이타 형식을 구현하거나 특정 작업을 수행하는 것들을 포함한다. 전형적으로, 프로그램 모듈의 기능은 다양한 실시예에서 요구되는 바와 같이 결합되거나 분산될 수 있다. 더욱이, 본 기술분야의 당업자라면 본 발명이 다른 컴퓨터 구성을 가지고 실행될 수 있다는 것을 알 것이다. 본 발명과 함께 사용되기에 적합한 다른 공지의 컴퓨터 시스템, 환경, 및/또는 구성은 개인용 컴퓨터(PC), ATM(automated teller machine), 서버 컴퓨터, 휴대용 또는 랩탑 장치, 멀티프로세서 시스템, 마이크로프로세서기반 시스템, 프로그램가능한 가전장치, 네트워크 PC, 어플라이언스, 광, 환경 제어 소자, 미니컴퓨터, 메인프레임 컴퓨터 등을 포함하나 이에 제한되지 않는다. 본 발명은 통신 네트워크/버스나 기타의 데이타 전송 매체를 통해 링크되는 원격 처리 장치에 의해 작업이 수행되는 분산 컴퓨팅 환경에서 실행될 수도 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 로컬 및 리모트 컴퓨터 저장 매체 모두에 저장될 수 있고 클라이언트 노드가 반대로 서버 노드로 행동할 수 있다.

도 1은 본 발명이 구현되는 적절한 컴퓨팅 시스템 환경(100)의 예로서, 상기에서 명백히 설명한 바와 같이 이 컴퓨터 시스템 환경(100)은 적절한 컴퓨팅 환경의 일례일 뿐이고 본 발명의 이용이나 기능의 범위에 제한을 두려는 것은 아니다. 이 컴퓨팅 환경(100)은 예시적인 동작 환경(100)에 도시된 콤포넌트들 중 임의의 하나 또는 조합에 관하여 임의의 종속성(dependency) 또는 요구사항(requirement)을 갖는 것으로 해석되어서는 안된다.

도 1을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은 컴퓨터 시스템(110)의 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터 시스템(110)의 콤포넌트들은 프로세싱 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 포함하는 다양한 시스템 콤포넌트들을 프로세싱 유닛(120)에 결합시키는 시스템 버스(121)를 포함하나, 이에 제한되지 않는다. 시스템 버스(121)는 임의의 다양한 버스 구조를 이용하는, 메모리 버스나 메모리 콘트롤러, 주변 버스, 및 로컬 버스를 포함하는 임의의 여러 형식의 버스 구조가 될 수 있다. 예를 들어, 이러한 아키텍쳐는 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 로컬 버스, 및 PCI(Peripheral Component Interconnect) 버스(Mezzzanine 버스라고도 함)를 포함하나, 이에 제한되지 않는다.

컴퓨터 시스템(110)은 전형적으로 다양한 컴퓨터 판독가능한 매체를 포함한다. 컴퓨터 판독가능한 매체는 컴퓨터 시스템(110)에 의해 액세스될 수 있는 임의의 가용한 매체가 될 수 있고 휘발성 및 불휘발성, 분리형 및 비분리형 매체를 모두 포함한다. 예를 들어, 컴퓨터 판독가능한 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있으나, 이에 제한되지 않는다. 컴퓨터 저장 매체는 컴퓨터 판독가능한 명령들, 데이타 구조, 프로그램 모듈이나 다른 데이타와 같은 정보 저장장치를 위한 임의의 방법이나 기술로 구현되는 휘발성 및 불휘발성, 분리형 및 비분리형 매체를 포함한다. 컴퓨터 저장장치 매체는, RAM(Random Access Memory), ROM(Read Only Memory), EEPROM(Elecrically Erasable Programmable Read Only Memory), 플래시 메모리 또는 다른 메모리 기술, CDROM(Compacct Disk Read Only Memory), CDRW(compact disc-rewritable), DVD(digital versatile disk) 또는 임의의 다른 광학 디스크 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치 또는 다른 자지 저장장치, 또는 원하는 정보를 저장하는데 사용되고 컴퓨터 시스템(110)에 의해 액세스가능한 임의의 다른 매체를 포함한다. 통신 매체는 전형적으로 컴퓨터 판독가능한 명령, 데이타 구조, 프로그램 모듈 또는 모듈화된 데이타를 반송파와 같은 변조된 데이타 신호나 다른 전송 메카니즘으로 구현하고 임의의 정보 전달 매체를 포함한다. "변조된 데이타 신호"란 하나 이상의 특성 세트를 갖거나 신호내의 정보를 인코딩하는 방식으로 변경된 신호를 의미한다. 예를 들어, 통신 매체는 유선 네트워크나 직접 유선 접속과 같은 유선 매체를 포함하는 통신 매체, 및 음향, RF, 적외선 및 다른 무선 매체와 같은 통신 매체를 포함한다. 상기 중 임의의 조합이 또한 컴퓨터 판독가능한 매체의 범주 내에 포함될 수 있다.

시스템 메모리(130)는 ROM(131) 및 RAM(132) 등의 휘발성 및/또는 불휘발성 메모리의 형태의 컴퓨터 저장 매체를 포함한다. 시동중과 같은 때에 컴퓨터 시스템(110) 내의 구성요소들간에 정보를 전송하는 것을 돕는 기본 루틴을 포함하는 기본 입출력 시스템(133; BIOS)은 일반적으로 ROM(131)에 저장된다. RAM(132)은 일반적으로 프로세싱 유닛(120)에 즉시 액세스될 수 있고 및/또는 프로세싱 유닛(120)에 의해 현재 작동되는 프로그램 모듈 및/또는 데이터를 포함한다. 예로서, (한정하고자 하는 것은 아님) 도 1은 오퍼레이팅 시스템(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)를 도시한다.

컴퓨터 시스템(110)는 또한 다른 분리형/비분리형, 휘발성/불휘발성 컴퓨터 저장 매체를 포함할 수 있다. 단지 예로서, 도 1에는 비분리형 불휘발성 자기 매체로부터 판독하거나 그 자기 매체에 기록하는 하드 디스크 드라이브(140), 분리형 불휘발성 자기 디스크(152)로부터 판독하거나 그 자기 디스크에 기록하는 자기 디스크 드라이브(151), 및 CD-ROM 또는 기타 광학 매체 등의 분리형 불휘발성 광학 디스크(156)로부터 판독하거나 그 광학 디스크에 기록하는 광학 디스크 드라이브(155)가 도시되어 있다. 예시적인 오퍼레이팅 환경에서 사용될 수 있는 다른 분리형/비분리형, 휘발성/불휘발성 컴퓨터 저장 매체는 자기 테이프 카세트,플래쉬 메모리 카드, DVD(Digital versatile disk), 디지털 비디오 테이프, 고체 RAM, 고체 ROM 등을 포함하지만 이에 한정되지 않는다. 하드 디스크 드라이브(141)는 일반적으로 인터페이스(140)와 같은 비분리형 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광학 디스크 드라이브(155)는 일반적으로 인터페이스(150)와 같은 분리형 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.

앞서 기술되고 도 1에 도시된 드라이브 및 그 관련 컴퓨터 저장 매체는 컴퓨터 시스템(110)를 위한 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 및 기타 데이터의 저장을 제공한다. 도 1에서, 예를 들어, 하드 디스크 드라이브(141)는 오퍼레이팅 시스템(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈(146), 및 프로그램 데이터(147)를 저장하는 것으로 도시된다. 이들 컴포넌트는 오퍼레이팅 시스템(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)와 동일할 수도 있고 다를 수도 있다. 오퍼레이팅 시스템(144), 애플리케이션 프로그램(145), 다른 프로그램 모듈(146), 및 프로그램 데이터(147)는 최소한 다른 복사본(different copies)임을 나타내기 위하여 다른 번호를 부여하였다. 사용자는 일반적으로 마우스, 트랙볼, 또는 터치 패드라 불리우는 포인팅 장치(161) 및 키보드(162)와 같은 입력 장치를 통해 컴퓨터 시스템(110)에 명령 및 정보를 입력할 수 있다. (도시되지 않은) 기타 입력 장치는 마이크로폰, 조이스틱, 게임 패드, 위성 안테나, 스캐너 등을 포함할 수 있다. 이들 입력 장치 및 그외의 입력 장치는 시스템 버스에 연결된 사용자 입력인터페이스(160)를 통해 종종 프로세싱 유닛(120)에 접속되지만, 병렬 포트, 게임 포트 또는 유니버설 시리얼 포트(USB) 와 같은 기타 인터페이스 및 버스 구조에 의해 접속될 수 있다. 모니터(191) 또는 다른 유형의 디스플레이 장치는 또한 비디오 인터페이스(190) 등의 인터페이스를 통해 시스템 버스(121)에 접속된다. 모니터외에도, 컴퓨터는 또한 출력 주변 인터페이스(195)를 통해 접속될 수 있는 스피커(197) 및 프린터(196) 등의 기타 주변 출력 장치를 포함할 수 있다.

컴퓨터 시스템(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용한 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어(peer) 장치, 또는 기타 공통 네트워크 노드일 수 있으며, 비록 도 1 에는 메모리 저장 장치(181)만이 도시되어 있지만, 컴퓨터 시스템(110)에 관하여 상술한 구성요소 중 다수 또는 모든 구성요소를 일반적으로 포함할 수 있다. 도시된 논리적 접속은 근거리 통신망(LAN; 171) 및 원거리 통신망(WAN; 173)을 포함하지만, 그 외의 네트워크를 포함할 수도 있다. 이러한 네트워크 환경은 사무실, 기업 광역 컴퓨터 네트워크(enterprise-wide computer network), 인트라넷, 및 인터넷에서 일반적인 것이다.

LAN 네트워크 환경에서 사용되는 경우, 컴퓨터 시스템(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워크 환경에서 사용되는 경우, 컴퓨터 시스템(110)는 일반적으로 인터넷 등의 WAN(173)을 통해 통신을 구성하기 위한 모뎀(172) 또는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 기타 적절한 메카니즘을통해 시스템 버스(121)에 접속될 수 있다. 네트워크 환경에서, 컴퓨터 시스템(110)에 관하여 도시된 프로그램 모듈 또는 그 일부분은 원격 메모리 저장 장치에 저장될 수 있다. 예로서 (한정하고자 하는 것은 아님), 도 1은 메모리 장치(181)에 상주하는 원격 애플리케이션 프로그램(185)을 도시한다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들간의 통신 링크를 구성하는 그 외의 수단이 사용될 수 있다.

다양한 분산형 컴퓨팅 네트워크는 퍼스널 컴퓨팅 및 인터넷을 중심으로 개발되어 왔으며 개발 중에 있다. 개인 및 비즈니스 사용자를 막론하고, 컴퓨팅 활동을 점점 웹 브라우저 지향적 또는 네트워크 지향적으로 만드는 애플리케이션 및 컴퓨팅 장치에 대하여 이음새없이 상호 동작이 가능하고 웹 사용가능한 인터페이스(seamlessly interoperable and web-enabled interface)가 제공된다.

예를 들어, 마이크로소프트사(One Microsofr Way, Redmond, Washington 98052)로부터 구할 수 있는, MICROSOFT의 .NET^TM플랫폼은 서버, 웹-기반 데이터 저장과 같은 빌딩-블록 서비스, 및 다운로드 가능한 장치 소프트웨어를 포함한다. 예시된 실시예는 컴퓨팅 장치 상에 상주하는 소프트웨어와 관련하여 기재되지만, 본 발명의 하나 이상의 부분은, 서비스가 모든 .NET^TM의 언어 및 서비스에 의해 수행될 수 있거나, 지원될 수 있거나, 이를 통해 액세스될 수 있도록, 모든 오퍼레이팅 시스템, 애플리케이션 프로그래밍 인터페이스(API), 또는 코프로세서(coprocessor)와 요구 오브젝트간의 "미들 맨(middle man)" 오브젝트를통해 구현될 수 있을 뿐 아니라, 기타 분산형 컴퓨팅 프레임워크에서 구현될 수도 있다.

<예시적인 실시예>

도 2는 본 발명의 특징들을 구현하는 예시적인 시스템 아키텍쳐의 블럭도를 도시한다. 중간 언어 컴파일러와 타겟 실행 엔진을 포함하는 쿼리 런타임 아키텍쳐(200)가 도시된다. 이 아키텍쳐는 다수의 데이타 소스 상의 XML 쿼리를 위한 데이타를 수신, 컴파일, 해석, 및 액세스하도록 구현된 예시적인 기본 블록을 도시한다. 복수의 프론트엔드 언어 컴파일러(210)가 실현될 수 있는데, 이들은 XML 또는 XML 관련 표준에 적합하다. 원래의 또는 입력된 쿼리가 수신될 수 있고 또는 도 1에 도시된 바와 같은 복수의 입력 장치들 중 임의의 하나로부터 수신될 수 있다. 도 2로 돌아가면, 프론트엔트 컴파일러(210)는 XML 쿼리, XML 뷰, 또는 다른 관련 XML 언어 질의(inquiries)를 수신하여 입력 쿼리의 의미의 컴파일된 XML 중간 언어 표현(215)를 생성할 수 있다. 프론트엔드 컴파일러를 위한 전형적인 언어 형식은 W3C(World Wide Web Consortium)이 공표한 표준, XPath, XML Stylesheet Language(XSL), XSLT, XQuery(XML Query Language)를 포함한다. XML 뷰 컴파일러도 있으며 무엇보다도 XQuery의 W3CXML 표준 뷰를 포함한다. 쿼리와 뷰 언어들 간의 중간 언어 추상화 및 다중 타겟 모델은 Microsoft.NET^TM의 실제 XML 데이타 뿐만 아니라 가상 XML 데이타가 데이타 소스로서 사용되도록 한다.

관련 타겟 쿼리 언어 실행 엔진(230)의 다중성(multiplicity)을 지원하기 위한 복수의 백엔드 타겟 생성기(220)가 있을 수 있다. 각 백엔드 타겟 생성기(220)는 각 지원된 데이타 소스 내에서 데이타 모델과 맞는 데이타 소스에 효과적으로 작용하도록 구성될 수 있다. 예를 들어, SQL 데이타베이스 소스를 위한 타겟 쿼리 언어 생성기는 SQL 데이타베이스 관리 시스템과 관련된 데이타베이스를 조회를 하는 효율이 최적화될 수 있다. 따라서, 예를 들어, 타겟 쿼리 언어 생성기(220a)는 또한 실행 엔진(230a)와 쌍을 이루어 중간 언어 표현을 특정 데이타 소스(240)와 호환가능한 타겟 기계 언어로 변환시킬 수 있다. 선택적으로, 타겟 생성기는 또한 XML 중간 언어 표현(215)를 다른 중간 언어, 예컨대 Microsoft중간 언어(MSIL)와 같은 다른 중간 언어로 변환시켜, 실행 엔진이 하나 이상의 데이타 소스(240)를 직접 조회할 수 있도록 할 수도 있다.

컴파일된 쿼리를 실행하면, 실행 엔진은 통상적으로 이후의 예컨대, 처리, 저장, 사용자에게 디스플레이, 또는 후속 소프트웨어 애플리케이션에 대한 준비에 사용될 수 있는 쿼리 결과(250)을 생성한다. 타겟 생성기(220)과 대응하는 실행 엔진(230)은 XML과 SQL과 같은 쿼리 언어들을 포함할 수 있다.

본 아키텍쳐의 다른 측면은 데이타 가용성의 변조성(modularity)이다. 예를 들어, XML 중간 언어 표현(215)이 생성되는 지점에서, 출력이 생성되어 이 중간 언어 표현 자체가 다른 시스템에 사용가능하거나 지연된 타겟 컴파일링에 사용가능할 수 있다. 또한, 이 XML 중간 언어 자체는 실제로 특정, 비XML 중간 언어 명령어 쿼리로 먼저 변환하지 않고 직접 실행될 수 있다. 따라서, XML 중간 언어는 이 XML 중간 언어 표현을 실행하기도록 특별히 만들어진 실행 엔진을 사용하여 컴파일러 없이 하나 이상의 데이타 소스를 조회를 하는데 사용될 수 있다. 시스템 출력의 다른 선택사항으로서 타겟 생성기 출력(들)이 별도의 시스템에서의 실행을 위한 출력으로서 또는 다른 비시스템 애플리케이션에 의해 사용될 수 있다.

도 2의 예시적인 아키텍쳐는 본질적으로 쿼리를 구성하는데 많은 유연성을 허용한다는 것을 알아야 한다. 이 쿼리 아키텍쳐는 다수의 쿼리들의 중간 언어 조합이 생성될 수 있도록 다수의 쿼리들이 입력되도록 한다. 또한, 다수의 백엔드 타겟 생성기 및 실행 엔진들이 상이한 데이타 모델들의 데이타 소스들를 조회를 하는데 적절히 사용된다. 아키텍쳐(200)는 또한 프론트엔드 및 백엔드의 순열(permutation)의 수를 감소시킨다. 도 2는 M개의 프론트엔드 컴파일러와 N개의 백엔드 컴파일러를 도시하며, 여기서 M과 N은 정소이다. 통상적으로 이 조합은 총 M 곱하기 N개의 가능한 시스템 경로가 나올 것이다. 그러나, 공통의 중간 언어의 사용으로 인하여, 순열의 수는 M 더하기 N으로 유리하게 줄어든다.

도 2에 도시된 바와 같이 생성된 XML 중간 언어는 XML 쿼리나 뷰의 표현이다. 이와 같이, 이는 XML 쿼리의 의미를 명백하게 표현하는 것이므로 쿼리 중간 언어(QIL)라고 할 수 있다. 쿼리 중간 언어(QIL)는 모든 쿼리 및 뷰 언어 컴파일러에 걸쳐 공통적인 의미론적인 표현으로 보일 수 있다. QIL은 통상의 추상 구문 트리(AST: abstract syntax tree)와 유사하나 QIL이 그 언어의 구문이 아니라 의미(semantics), 또는 쿼리의 의미를 포착한다는 점에서 다르다. 또다른 차이점은 QIL은 그래프 구조이고 AST와 같은 트리 구조가 아니라는 점이다.

QIL은 다수의 상이한 XML 쿼리 언어 및 뷰 정의 언어(XPath, XSLT, XQuery)의 추상화를 다양한 상이한 타겟 데이타 소스(관계형 및 비관계형 데이타) 상에서 가능하게 한다. 이와 같이 QIL은 모든 호환가능한 XML 언어들을 지원하기 위한 공통의 구조를 가능하게 한다. 모든 동작은 명백하고 모호하지 않은데, 바람직하게는 QIL을 사용하는 백엔드 엔진으로부터 QIL을 생성하는 것을 돕는 프론트엔드 컴파일러를 완전히 분리한다.

예시적인 쿼리 중간 언어 정의가 공동 출원된 마이크로소프트사(Redmond, WA)의 특허 출원 QUERY INTERMEDIATE LANGUAGE METHOD AND SYSTEM(출원번호 XX/XXX,XXX, 동일자로 출원됨)에 제공된다. 이 공동 출원의 내용은 본 출원에 참고로 전체가 포함된다.

도 3은 공통 쿼리 런타임 아키텍쳐(예컨대, 도 2에 관해 기술된 예시적인 아키텍쳐)의 예시적인 API(application programming interface)에 대한 흐름도이다. API가 (예컨대, 도 2의) 시스템에 상주하는 것으로 보일 수 있으며 이 시스템을 이용하는 애플리케이션이 이 애플리케이션과 통신하는 것을 허용한다. 이 통신은 시스템 자원들이 이 애플리케이션에 가용해지도록 한다. 도 3으로 돌아가면, 입력 쿼리를 수신하고, 그 쿼리를 XML 중간 언어로 컴파일하고, 이 중간 언어 표현을 타겟 언어로 변환하고, 이 타겟 컴파일을 실행하고, 쿼리 결과를 생성하는 과정이 여기 기술되어 있으며 예시적인 애플리케이션 인터페이스가 표시되어 있다.

초기에, 애플리케이션은 입력 쿼리(310)의 수신을 제공하거나(315) 이를 인식하게 된다. 애플리케이션은 쿼리 시스템과 인터페이싱하여 소프트웨어 환경 제어 파라미터를 설정하고 제어 옵션들(320)을 컴파일하기 위한 하나 이상의콜(call)을 만든다. 이 단계는 하나 이상의 프론트엔드 컴파일러 구조가 입력 쿼리를 수신하고 소프트웨어 및 제어된 파드웨어를 입력 쿼리의 컴파일을 위해 준비하도록 한다. 애플리케이션은 모니터링 기능(390)에 대한 상태 콜을 통해 애플리케이션이 원하는 파라미터 설정 상태 및 진행 상황을 모니터링할 수 있다(322).

이 쿼리 시스템 파라미터들은 쿼리 시스템으로 통과되고(325) 애플리케이션은 그 다음 쿼리 시스템과 인터페이싱하여 입력 쿼리(310)의 중간 언어 표현(330)을 컴파일하여 입력 쿼리의 XML 의미론적 의미에 도달한다. 이 의미론적 의미는 지연된 처리 또는 상이한 시스템에서의 사용을 위한 애플리케이션 제어를 통해 시스템(330)으로부터 모니터링되거나 출력될 수 있다. 모니터링 기능(390)은 애플리케이션이 중간 언어를 생성함에 있어서뿐 아니라 제어장치의 등록 및 환경 설정에 있어서 시스템의 성능을 모니터링하도록 한다. 일단 중간 언어 표현이 생성되면, 사용자 목적을 위한 모니터링이나 출력 기능 뿐만 아니라 원하는 다른 애플리케이션으로 전달될 수 있다(332). 달리, 이 중간 언어 표현은 타겟 생성기에 의한 컴파일을 위한 소프트웨어 모듈에 전달될 수 있다(334). 다른 방법으로 이 중간 언어 표현을 직접 실행을 위한 쿼리 실행 엔진으로 전달할 수도 있다(336).

이 중간 언어 표현이 타겟 생성기로 전달되면, 애플리케이션은 쿼리 시스템에 콜(340)을 생성하여 타겟 생성기를 선택하고 적절히 컴파일러를 구성하고, 타겟 생성기 출력을 생성할 수 있다. 이전과 같이, 애플리케이션은 타겟 생성기 설정과 액티비티를 모니터링하여(342) 애플리케이션과 쿼리 시스템 모두의 동작을 보장할 수 있다. 이미 언급한 바와 같이, 이 시점에서 사용가능한 제품, 타겟 특정 쿼리가 생성되었으므로, 이 쿼리 시스템은 애플리케이션을 통해 정지 또는 서스펜드 상태가 될 수 있다. 이 타겟 특정 쿼리는 장래의 사용을 위해 저장될 수 있고 또는 다른 시스템에 의해 사용되어 하나 이상의 데이타 소스를 조회를 할 수 있다.

쿼리 시스템 동작이 계속된다고 가정하면, 이 타겟 특정 쿼리는 쿼리를 실행할 수 있는 실행 엔진에 전달될 수 있다(345). 애플리케이션은 콜을 생성하여(350) 타겟 특정 쿼리를 하나 이상의 데이타 소스(380) 상에서(356) 실행할 수 있다. 이전에 언급한 것과 같이, 애플리케이션은 실행 엔진의 설정과 액티비티를 모니터링하여(352) 쿼리 시스템의 적절한 동작을 보장한다.

실행이 완료되면, 실행 엔진은 그 쿼리 결과를 원하는 경우 추가의 처리를 위해 쿼리 시스템이 일시적으로 쿼리 결과(360)를 보유하고 있는 축적기(accumulator)에 전달한다(355). 이 쿼리 결과는 그 결과들이 전달되거나 모니터링되는 애플리케이션(362)로부터의 콜을 통해 액세스가능하다.

예시적인 애플리케이션 프로그래밍 인터페이스

본 발명에 따른 API 인터페이스의 예는 이하와 같다.

I. 프론트엔드 컴파일러 커맨드:

다양한 XML 쿼리 언어들로부터 QIL의 캡슐화인, XmlExpressions을 생성하는데 쿼리 컴파일러들이 사용된다. XML 쿼리 언어에 대한 세개의 컴파일러 예가 다음과 같이 주어진다: XPathCompiler, XsltCompiler, XQueryCompiler. 이 컴파일러의 전형적인 사용에는 XmlEnvironmentBase의 설정과 쿼리의 컴파일이 포함된다.

적절한 XmlComplilerEnvironmentBase 컴파일러 환경이 컴파일동안 사용되어쿼리에 관계없는 컴파일러들에 정보를 제공할 수 있다. 예를 들어, XPath 구문(syntax) 단독으로는 다른 네임스페이스(namespace)으로 조회를 하는 것을 허락하지 않는다. 컴파일러 환경에서 XmlNamespaceResolver가 적절한 네임스페이스 URI들로 프리픽스(prefix)들을 매핑하도록 설정되면, XPath 쿼리는 이제 다른 네임스페이스들로 조회를 할 수 있게 된다. 컴파일러 환경이 대부분의 쿼리의 실행에 필수적인 것은 아니라는 점에 유의한다.

쿼리의 컴파일은 통상적으로 적절한 컴파일러 환경이 특정된 후 일어난다. 그 때, 실제 쿼리가 사용자나 다른 입력 소스에 의해 제공되고 컴파일될 수 있다. 이 컴파일의 결과는 XmlExpression이다. 흔히, 쿼리는 관련 증거(Evidence) 오브젝트에 제공된다. 이 증거 오브젝트는 주어진 쿼리의 신용상태와 따라서 수행될 수 있거나 수행될 수 없는 액션이 무엇인지를 특정하고 따라서 쿼리의 보안 레벨을 적용한다.

증거 기반 보안(evidence based security)은 보안 허가를 통해, 사용자가 쿼리 자체를 얼마나 많이 실행할 수 있는지를 정확히 특정하는 옵션을 가능하게 한다. 예를 들어, 어떤 액세스가 허용되든지간에, 데이타베이스에 대한 접속과 같은 데이타 액세스의 임의의 소트를 필요로 하는 임의의 쿼리는 실패할 것이다. 성공할 수 있는 유일한 쿼리는 정적인 결과(예컨대, "수자(3+5)")를 반환하는 것들로, 데이타베이스로부터 데이타가 액세스되지 않기 때문이다. 이 데이타 소스는 어떠한 방식으로든 변경되지 않는다는 것이 보장될 것이다. 이는 XPath Navigator API의 능력들로 매핑한다. 추가 액세스가 허용되면, INSERT 문장만이 실행될 것이다.이는 추가하는 것만을 허용하면서 원래의 데이타는 어떠한 방식으로든 변경되지 않는다는 것을 보장한다. 무제한적인 액세서가 허용되면, 갱신이 실행될 수 있다. 이는 임의의 데이타 소스에서 데이타를 완전히 삭제하는 것을 포함한다. 이는 XPath Editor API의 능력으로 매핑한다.

A. XPath 컴파일러 클래스

1. 커맨드:

설명: 이 클래스의 인스턴스를 구성하는 메소드 커맨드. XmlComplilerEnvironmentBase가 제공되면, XmlComplilerEnvironment가 인스턴스로서 설정된다.

인수: XmlComplilerEnvironment;

XmlComplilerEnvironmentBase를 이 클래스의 인스턴스 상의 XmlComplilerEnvironment로 설정한다.

2. 커맨드:

설명: 컴파일 동안 메세지를 검색하기 위해 레지스터되는 이벤트. 컴파일러는 사용자가 반응할 수 있는 경고 및 다른 메세지들을 보고할 수 있다. 이 이벤트는 컴파일을 금지하지 않는다.

3. 커맨드:

설명: XML Compiler Environment 속성. 사용자가 사용할XmlComplilerEnvironmentBase를 얻거나 설정하도록 한다. 이 컴파일러 환경은 쿼리 자체로 전달되지 않는 정보를 쿼리 컴파일러에 제공한다.

4. 커맨드:

설명: 컴파일 메소드. 이 함수는 주어진 쿼리, XPath 쿼리를 컴파일하고, 주어진 쿼리의 QIL 표현인 XmlExpression을 반환한다. 주어진 쿼리의 신뢰성은 콜링 코드의 것과 동일하게 설정되는 것이 바람직하다.

인수: query;

XmlExpression으로 컴파일될 쿼리.

컴파일된 쿼리인 이 XML expression을 반환한다.

B. XSLT 컴파일러 클래스 - XsltComiler는 XSLT 스타일시트를 XmlExpresstion으로 컴파일하도록 고안됨.

1. 커맨드:

설명: 컴파일러 메소드. 이 클래스의 인스턴스를 구성한다. XmlCompilerEnvironmentBase가 제공되면, 이 인스턴스에 대해 XmlCompilerEnvironmentBase로서 설정된다.

인수:

XmlCompilerEnvironmentBase는 이 클래스의 인스턴스 상에XmlCompilerEnvironment로서 설정된다.

2. 커맨드:

3.커맨드:

설명: 사용자가 사용할 XmlComplilerEnvironmentBase를 얻거나 설정하도록 하는 속성. 이 컴파일러 환경은 컴파일되는 실제 쿼리에 더하여 쿼리 에 정보를 제공한다. XmlComplilerEnvironment의 디폴트 인스턴스.

4.커맨드:

설명: 컴파일 메소드. queryUri는 XmlResolver 파라미터를 통해 리졸브되고 XSLT 스타일시트로서 컴파일된다. XmlResolver 파라미터는 또한 원래의 스타일시트를 컴파일하는데 사용되는 임의의 xsl:include 및 xsl:import 스테이트먼트를 리졸브하는데도 사용된다. 전달된 증거는 주어진 쿼리의 신뢰도와 이어서 그것이 실행할 수 있는 액션들을 이 무엇인지를 결정하는데 사용된다. 증거 없이 오버로드가 사용되면, 주어진 URI는 쿼리에 대해 적절한 증거를 생성하는데 사용된다. 컴파일된 쿼리인 XMLExpression을 반환한다.

인수: queryUri;

URI는 컴파일할 XSLT 스타일시트를 검색하도록 리졸브된다.

resolver:

XSLT 스타일시트 및 이 스타일시트 내의 임의의 xsl:include 및 xsl:import를 리졸브하는데 사용됨

evidence;

주어진 쿼리의 신뢰성을 판정하는 보안 증거.

5. 커맨드:

설명: 컴파일 메소드. 이 기능은 XmlReader를 통해 전달된 XSLT 쿼리를 나타내는 XmlExpression을 반환한다. 전달된 이 Evidence는 주어진 쿼리의 신뢰성 및 이어서 실행될 수 있는 액션이 무엇인지를 결정하는데 사용된다. 증거 없는 오버로드가 사용되면, 컴파일러는 IDataEvidence 인터페이스를 통해 적절한 증거를 얻으려고 시도할 것이다. 이 인터페이스가 구현되지 않으면, 적절한 예외가 있다. 컴파일된 쿼리인 XmlExpression를 반환한다.

인수: query;

XmlExpression으로 컴파일될 XSLT를 포함하는 XmlReader.

resolver;

주어진 XSLT에서 xsl:include 및 xsl:import를 리졸브하는데 사용됨.

evidence;

주어진 쿼리의 신뢰성을 판정하는 보안 증거.

C. XQuery 컴파일러 클래스

1. 커맨드:

설명: 컴파일러 메소드. 이 클래스의 인스턴스를 구성한다. XmlComplilerEnvironmentBase가 제공되면, XmlComplilerEnvironment가 인스턴스로서 설정된다.

인수: XmlComplilerEnvironment;

2. 커맨드:

3.커맨드:

설명: XML 컴파일러 환경 속성. 사용자가 사용할 XmlComplilerEnvironmentBase를 얻거나 설정하도록 하는 속성. 이 컴파일러 환경은 컴파일되는 실제 쿼리에 더하여 쿼리 에 정보를 제공한다. 이는 XmlComplilerEnvironment의 디폴트 인스턴스이다.

4. 커맨드:

설명: 컴파일 메소드. 이 함수는 전달된 XQuery 쿼리를 나타내는 XmlExpression을 반환한다. 전달된 증거는 이 쿼리가 실행을 허용해야 하는 것을 결정하는데 사용된다.

인수: query;

XmlExpression으로 컴파일될 쿼리.

evidence;

주어진 쿼리의 신뢰성을 판정하는 보안 증거.

5. 커맨드:

설명: 이 함수는 주어진 쿼리에 대한 XmlExpression을 컴파일하고 반환한다. 제공된 증거는 주어진 쿼리의 신뢰성을 보여준다.

인수: query;

XmlExpression으로 컴파일될 쿼리를 포함하는 스트링.

evidence;

주어진 쿼리의 신뢰성을 판정하는 보안 증거.

6. 커맨드:

설명: queryUri는 XmlResolver 파라미터를 통해 리졸브되고 XQuery로서 컴파일된다. 컴파일된 쿼리인 XmlExpression을 반환한다.

인수: queryURI;

컴파일할 XQuery를 검색하기 위해 리졸브하는 URI.

resolver;

컴파일할 XQuery를 리졸브하는데 사용되는 XmlResolver.

II. 컴파일러 환경 커맨드

보통, 컴파일러 환경은 쿼리 컴파일러에 추가의 정보를 제공하여 실제 쿼리를 컴파일하는 것을 돕는데 사용된다. 특히, 이 인터페이스는 외부의 기능, 변수, 및 쿼리를 컴파일하기를 원하는 디폴트 문서를 리졸브하는데 사용된다. 모든 리졸브들이 XmlExpression을 반환해야 한다는 것에 유의하는 것이 중요하다.

함수 레졸루션의 한 예는 XmlViewSchema와 map:view() 함수이다. 쿼리 언어는 매핑이 포함된 개념을 내장하고 있지 않으므로 이것이 일어나도록 하는 확장자(extension)가 필요하다. XmlViewSchema는 map:view() 함수를 XmlExpression로 리졸브하는 능력을 갖고 따라서 개별 컴파일러에 의해 사용될 수 있다. 가변 리졸브가 매우 동일한 방법으로 작동할 수 있다. 컴파일러는 쿼리 구문에서 선언되지 않은 변수에 걸쳐 판독을 할 수 있다. 이는 XPath가 컴파일러 환경을 요구하는 다른 영역이다. 컨텍스트 문서 리졸브에서 모든 XML 쿼리 언어는 디폴트나 콘텍스트 문서를 조회해야 한다.

XmlComplilerEnvironmentBase는 완전한 컴파일러 환경인 추상 클래스이다. 이 클래스는 단지, 동적인 동작을 수행하도록 하는 주어진 컴파일러가 필요로 하는다양한 아이템들을 리졸브하는 능력을 갖고 있다. XmlComplilerEnvironmentBase는 쿼리 컴파일러가 이용하는 환경이다. 이는 임의의 주어진 컴파일러가 필요로 할 수 있는 대다수의 옵션들의 리졸브를 제공할 수 있다. 이는 IXmlCompilerInclude, IXmlNamespace 상에서 모든 방법을 구현할 수 있다. IXmlCompilerInclude를 구현함에 더하여, XmlComplilerEnvironmentBase는 또한 스키마, 네임스페이스, 및 쿼리가 컴파일되어야 하는 방식과 같은 다른 아이템들의 리졸브를 가능하게 한다.

XQuery는 쿼리의 컴파일 동안 W3CXml Schema(Xml Schema Definition-XSD)를 이용하여 정적 형식의 리졸브를 할 능력을 갖는다. 컴파일러 환경은 이러한 스키마들의 리졸브를 제공한다. 네임스페이스/프레픽스 리졸브는 사용자가 통상적으로 사용되는 컴파일들 간의 프레픽스-네임스페이스 결합을 쿼리 자체에서 각 시간에 특정할 필요없이 재사용할 수 있도록 이용될 수 있다. 이 기능은 IXmlNamespaceResolver를 구현함으로써 제공될 수 있다. 내장형(build type) API 명령어들이 사용자가 문제들을 보다 효과적으로 발견할 수 있도록 제공된다.

XmlEnvironmentBase에 대한 리졸브를 제공함에 더하여, 이러한 리졸브된 아이템들을 환경에 추가하는 방법이 제시된다. XmlComplilerEnvironment는 컴파일러에서 사용하기 위한 적어도 세개의 상이한 방법을 통하여 기능들을 추가할 수 있다. XmlComplilerEnvironment는 IXmlCompilerInclude를 구현한 것들을 취하고 이들을 주어진 함수의 리졸브용으로 사용할 수 있다. 본질적으로 "ResolveFunction" 방법 콜이 추가된 구현예 상으로 전달되어 그것을 리졸브하려고 할 것이다. 컴파일러 환경은 또한 사전 컴파일링된 쿼리 라이브러리를 XmlExpression 형태로 추가할 수 있다. 쿼리 라이브러리는 단일의 XmlExpression으로 컴파일된 사용자 정의된 XQuery 함수들의 그룹으로 정의될 수 있다. 이러한 방식으로, 임의의 쿼리 언어는 외부 함수로 콜을 보냄으로써 XQuery의 능력을 이용할 수 있다. 주어진 함수에 대해 쿼리 라이브러리로 파라미터들이 적절히 매핑될 수 있다. 컴파일러 환경은 또한 쿼리 라이브러리가 아닌 XmlExpression도 추가할 수 있다. 개별적인 컴파일 쿼리들(XPath 또는 XSLT)가 쿼리 함수로서 추가될 수 있다.

XmlComplilerEnvironment는 또한 다양한 방법을 사용하여 변수들을 추가할 수 있다. XmlComplilerEnvironment는 IXmlCompilerInclude를 구현한 것들을 취하여 이들을 주어진 변수의 리졸브에 사용할 수 있다. 본질적으로 "ResolveVariable" 메소드 콜이 추가된 구현예 상으로 전달되어 그것을 리졸브하려고 할 것이다. 컴파일러 환경은 또한 기존의 XmlExpression이 변수로서 이용되도록 할 수 있다. 이는 XmlExpression을 함수로서 추가하는 것과 유사하다. 이는 사용자에게 상이한 언어 중 특정 언어의 특징을 이용하는 능력을 제공한다. 일반적인 오브젝트를 변수로서 추가하는 것은 사용자들이 이 오브젝트의 값들을 그들의 쿼리 내에서 결합시키도록 한다. 오브젝트는 적절한 XSP 형식 및 쿼리에서 사용되는 값으로 변환된다.

XmlComplilerEnvironment는 쿼리 컴파일러에 의해 사용될 수 있는 컨텍스트 문서를 설정할 수 있다. 적절한 컨텍스트 문서를 XmlComplilerEnvironment 상으로 설정하는 데는 적어도 세가지 방법이 있다. IXmlCompilerInclude를 구현하는 오브젝트는 쿼리의 컨텍스트 문서를 설정하는데 사용될 수 있다.XmlComplilerEnvironment는 단순히 ResolveContextDocument() 메소드 콜을 문서 리졸브를 위한 IXmlCompilerInclude에 보낼 수 있다. 이것의 예는 XmlViewSchema이다. 이는 사용자들이 map:view() 함수를 사용하지 않고 매핑을 이용할 수 있도록 한다. XmlExpression도 컨텍스트 문서로 설정될 수 있을 것이다. 이러한 방식으로, 사용자는 매핑 지원으로 할 수 있는 만큼 쿼리를 통해 가상 XML 뷰를 형성할 수 있다. 사용자가 단순한 매핑에 노출되고 변개의 쿼리에서 추가의 논리를 갖는 것이 모두 밀접히 결합되는 것보다 쉬울 것이다. XSLT와 XQuery와 같은 언어들은 컨텍스트와 명명된 문서 상에서 동시에 조회할 능력을 갖는다. 이 컨텍스트 문서 리졸브를 URI로 설정함으로써, 컨텍스트 문서가 묵시적으로 제공되기보다 동적으로 리졸브되도록 재조정할 수 있다. 그 결과 사용자가 컨텍스트 문서와 XmlResolver 조합보다는 단일한 XmlResolver를 특정하여 조회를 하는 것이 프로그래밍을 더 쉽게 한다.

변수나 함수들이 XmlComplilerEnvironment에 추가되는 순서는 리졸브가 성공적으로 일어나는 순서에 영향을 미칠 수 있다는 것에 유의해야 한다. 한 처리 출은 명시적으로 명명된 함수/변수들이 성공적인 매칭을 위해 확인된다는 것을 지원한다. 복제(Duplicate) 명명된 함수/변수들은 성공적으로 추가되지 않을 수 있다. 단일한 XmlExpression에 포함되는 쿼리 라이브러리가 이 카테고리에 들어간다는 점에 유의한다. 다른 처리 룰은 IXmlCompilerInclude들이 추가되는 순서에 따라 매칭을 위해 연속적으로 테스트된다는 것을 지지한다. IXmlCompilerInclude는 복제 함수/변수를 다른 아이템들로서 포함할 수 있다. 그것이 명시적으로 명명된 함수/변수의 복제를 포함하면, 이 명시적으로 명명된 함수/변수는 먼저 리졸브될 것이므로 절대 리졸브되지 않을 수 있다. 다른 IXmlCompilerInclude가 복제 함수/변수를 포함하면, 단지 첫번째로 추가된 IXmlCompilerInclude가 주어진 아이템을 리졸브할 것이다.

예를 들어, XmlComplilerEnvironment가 생성되고 두 개의 IXmlCompilerInclude를 함수 리졸브에 추가하면, 실제 함수들을 리졸브하려고 할 때, 제1 IXmlCompilerInclude가 확인될 것이다. 이 리졸브가 실패하면, 제2 IXmlCompilerInclude가 성공적인 리졸브를 위해 확인될 것이다. 명명된 함수가 XmlExpression을 가지고 이 환경에 추가되면, IXmlCompilerInclude가 구현되기 전에 이것이 확인될 것인데, 명시적으로 명명된 함수/변수들이 IXmlCompilerInclude의 구현 전에 확인될 수 있기 때문이다.

예시적인 컴파일러 커맨드는 이하와 같다.

1. 커맨드:

설명: 리졸브 함수 메소드. 이 메소드는 컴파일러가 컴파일 동안 외부 함수들을 리졸브하도록 한다. 전달된 이 네임과 인수들은 구현예의 리졸브에 사용된다. 리졸브가 실패하면, 이 함수는 널(null)을 반환한다. 이 함수의 결과들을 나타내는 XmlExpression을 반환한다. 리졸브가 성공하면 널을 반환한다.

인수:

찾고 있는 함수의 완전한 (fully qualified) 이름;

함수와 함께 호출되는 파라미터들을 나타내는 XmlExpression들의 어레이. XML 컴파일러 환경의 구현은 파라미터 형식 확인과 최적화를 위한 결정 동안 이 정보를 이용할 것이다.

2. 커맨드:

설명: 이 메소드는 컴파일 동안 컴파일러가 외부 변수를 리졸브하는 것을 허용한다. 이 변수의 완전한 이름이 리졸브에 사용된다. 리졸브가 실패하면, 이 함수는 널을 반환한다. 변수의 값을 나타내는 XmlExpression을 반환한다. 리졸브가 성공적이면, 널이 반환된다.

인수:

찾고 있는 변수의 완전한 이름.

3. 커맨드:

설명: 이 메소드는 어떻게 컨텍스트 문서가 검색되는지를 컴파일러가 동적으로 리졸브하도록 한다. 리졸브가 실패하면, 이 메소드는 널을 반환한다. 컨텍스트 문서가 어떻게 리졸브되는지를 나타내는 XmlExpression을 반환한다. 리졸브가 실패하면, 널이 반환된다.

4. 커맨드:

설명: 컴파일러가 주어진 네임스페이스에 대한 스키마를 검색한다.이 메소드는 스키마가 리졸브될 수 없으면 널을 반환한다. 주어진 네임스페이스에 대해 컴파일된 스키마인 XmlSchema 오브젝트를 반환한다. 이 스키마가 리졸브될 수 없으면, 널이 반환된다.

인수:

스키마를 리졸브하기 위한 네임스페이스.

5. 커맨드:

설명: 컴파일러가 디버그 특성을 가지고 쿼리를 컴파일해야 하는지 여부를 결정하도록 하는 속성.

6. 커맨드:

설명: 새로운 XmlComplilerEnvironment를 개시하는 메소드. IsDebug에 대한 값을 제공하는 오버로드가 제공되면, 이 값은 베이스 XmlComplilerEnvironment 클래스에 호출된 IsDebug 액세서 상에 반환될 것이다.

7. 커맨드:

설명:및메소드에 의한 리졸브에 사용되는속성

8. 커맨드:

설명: 이속성은형식의 정보를 설정하고얻기 위한메소드에 의한 리졸브에 사용된다.

9. 커맨드:

설명: 이 콘텍스트 문서 메소드는 사용자가의 구현으로부터 나오는 컨텍스트 문서의 리졸브를 설정하도록 한다.

인수:

컨텍스트 문서를 리졸브할 수 있는의 구현.

10. 커맨드:

설명: 이 문서 컨텍스트 메소드는 사용자가 XmlExpression으로서 디폴트 문서를 설정하도록 한다. 이는 다른 쿼리나 매핑 상에서 XSLT 또는 XPath의 구성에 유용할 것이다.

인수:

현재 환경을 사용하여 컴파일되는 쿼리의 디폴트 문서 레졸루션 대신 구성될 XmlExpression.

11. 커맨드:

설명: 이 문서 컨텍스트 메소드는 사용자가 런타임동안 문서를 리졸브하는 동안 사용될 디폴트 문서 이름을 설정하도록 한다. 이는 디폴트 문서 또는디폴트 문서와 명명된 문서의 조합만이 있는 XPath와 XSLT에 유용하다.

인수:

제공된 XmlResolver를 통해 런타임시 리졸브될 네임.

12. 커맨드:

설명: 이 함수 메소드는를 컴파일 동안가 함수들을 리졸브하는데 사용되는 것을 가능하게 하는 컴파일 환경에 더한다.

인수:

함수를 리졸브할 수 있는의 구현.

13. 커맨드:

설명: 이 함수 메소드는 기존의 XmlExpression을 함수 라이브러리로서 추가하는데 사용된다. 예: 사용자는 XmlExpression으로 컴파일되는 다중의 XQuery 함수들을 갖는다. 사용자는 그 다음 이 XmlExpression을 함수 라이브러리로서 추가하고 이것을 주어진 네임스페이스와 관련시킨다. 그 다음 이 함수들을 다른 쿼리들(XQuery에 한정되지 않음) 내에서 재사용한다.

인수: library;

이전에 컴파일된 함수들을 포함하는 컴파일된 XmlExpression.

14. 커맨드:

설명: 이 함수 메소드는 사용자가 XmlExpression을 다른 쿼리의 컴파일에 사용되는 함수로서 결합시키도록 한다. 예: XQuery에 대해, 전체 XQuery는 단일 함수로 고려될 것이다. XSLT에 대해, 전체 스타일시트는 단일 함수로서 고려될 것이다. XPath에 대해, 전체 XPath 표현은 단일 함수로 고려될 것이다.

인수: name;

쿼리에서 함수가 참조되는 완전한 이름.

Function;

결합되는 XML 표현.

15. 커맨드:

설명: 이 변수 리졸브 메소드는를 컴파일 동안가 변수들을 리졸브하는데 사용되는 것을 가능하게 하는 컴파일 환경에 더한다.

인수:

변수 리졸루션을 제공할 수 있는의 구현.

16. 커맨드:

설명: 이 변수 추가 메소드는 외부 파라미터를 특정 정의에 결합시킨다. XQuery에 대한 유효한 함수는 내부에 XQuery 함수를 포함하지 않는 것이다. 전체 XSLT 스타일시트는 변수로서 고려될 것이다. 전체 XPath 표현은 변수로서 고려될 것이다.

인수: name;

결합될 외부 파라미터의 이름.

variable;

변수를 정의하는 XmlExpression.

17. 커맨드:

설명: 공통 언어 런타임 오브젝트를 변수에 결합시키는 변수 추가 메소드. 오브젝트는 XSD 등가물로 변환되고 그 값이 이용된다.

인수: name;

결합될 외부 파라미터의 이름.

variable;

변수를 정의하는 공통 언어 런타임 오브젝트.

18. 커맨드:

설명: 변수를 아직 정의하지 않고 선언하는 변수 선언을 추가하는 메소드. 정의는 실행 시간에를 통해 제공될 것이다. 적절한 변수가에서 발견되지 않으면, 제공된가 대신 이용될 것이다.

인수: name;

선언될 변수의 완전한 이름.

type;

선언된 변수의.

;

변수의 디폴트 값.

III. XML Expression 커맨드

XMLExpression은 주어진 XML 쿼리의 컴파일된 형태이다. 이는 본질적으로 QIL이 캡슐화된 것이다. XMLExpression은 조합가능한 오브젝트이다. 즉, 일단 XMLExpression이 생성되면, 상이한 쿼리의 컴파일 동안 재사용되어 쿼리 라이브러리나 가상 뷰와 같은 추가의 기능을 가능하게 할 수 있다.

XMLExpression에서 이용가능한 적어도 두 개의 방법이 있다: 정적값이면 주어진 XmlExpression의 값을 검색하는데 사용될 수 있는 IXmlValueReader의 값 반환 및 XmlExpression의 XSD 형식을 검색하는데 사용될 수 있는 XmlShemaType 오브젝트의 타입 반환.

1. 커맨드:

설명: XmlExpression의 값인를 반환한다. 또한 이 값이 상수이면를 구현하는 오브젝트를 반환한다.

2. 커맨드:

설명: 이 속성은로서 표현되는 XmlExpression의 형식을 나타내는의 반환을 허용한다. 또한 값이 상수이면을 반환한다.

IV. 백엔드 타겟 쿼리 생성기 커맨드

타겟 쿼리 생성기(또는 타겟 언어 컴파일러)는 주어진 쿼리를 특정 데이타 소스 상에서 실행할 수 있는 오브젝트를 생성하는데 사용된다. 두 개의 예시적인 형태들이 여기서 기술된다. XmlILGenerator 엔진은 RXPathNavigator 또는 XPathEditor 구현 상에서 쿼리들을 실행할 수 있다. 이는 XmlCache와 같은, RXPathNavigator에 노출될 수 있는 임의의 데이타 소스가 '내장(built-in)'된 쿼리 능력들을 갖도록 한다. SQLGenerator 엔진은 XML Expression을 직접 처리할 수 있고 따라서 실행을 위한 SQL 스테이트먼트를 최적화할 수 있다.

A. XML 타겟 커맨드

1. 커맨드:

설명: 이 메소드 커맨드는 새로운를 구성한다.

2. 커맨드:

설명: 이 메소드 커맨드는 주어진 XmlExpression에 대한 XmlCommand를 생성한다. XmlCommand는 그 다음 쿼리의 결과를 검색하도록 수행될 수 있다. 쿼리의 실행가능한 형태인 XmlCommand을 반환한다.

인수: query;

XmlCommand가 생성되는 XmlExpression.

3. 커맨드:

설명: 생성 동안 메세지들을 수신하기 위해 레지스터되는 이벤트. Generator는 사용자가 반응할 경고 또는 다른 메세지들을 보고할 수 있다. 이 이벤트는 XMLCommand 생성을 막지 않는다.

B. SQL 타겟 커맨드

1. 커맨드:

설명: 이 생성기는 QIL을 취하고 데이타메이스에 대해 조회를 할 수 있다. 이 메소드는 새로운를 구성한다.

2. 커맨드:

인수: query;

XmlCommand가 생성되는 XmlExpression.

3. 커맨드:

V. XML 커맨드

XmlCommand는 쿼리 시스템 런타임에서 결과적인 출력 오브젝트들 중 하나가될 수 있다. 이는 사용자나 다른 프로그램에 의해 실행될 수 있는 물리적인 쿼리 플랜이다. XmlCommand는 쿼리를 수행하는데 사용되는 데이타 소스들 및 런타임 파라미터들의 리졸브를 제공한다.

1. 커맨드:

설명: 이 이벤트 커맨드는 쿼리 실행 동안 결과 세트의 일부가 아닌 정보를 사용자에게 되돌려 주는데 사용될 수 있다. 예를 들어, 일부 W3C쿼리 표준은 처리 동안 의존적인 행위를 실행하도록 한다. 실행 런타임은 이 행위를 사용자에게 보고할 수 있다.

2. 커맨드:

설명: 이 실행 메소드는 주어진에 런타임 파라미터로서 쿼리를 제공된상에서 실행한다. 그 결과는 제공된에 대한 출력이다.

인수:

조회하는 디폴트 문서.

는 쿼리를 실행하는데 사용될 수 있는 임의의 런타임 파라미터들을 포함할 수 있다.

results;

이 쿼리의 결과가 기록되는.

3. 커맨드:

설명: 이 실행 메소드는 런타임 파라미터로서 주어진상에서 쿼리를 실행한다. 그 결과는 제공된에 대한 출력이다. 이 오버로드는 업데이트되어보다는를 이용할 때 수행되도록 한다.

인수:

조회하는 디폴트 문서.

results;

이 쿼리의 결과가 기록되는.

4. 커맨드:

설명: 이 실행 메소드는를 통해 데이타소스들에 액세스하고에 의해 제공된 런타임 파라미터들을 이용하여 쿼리를 실행한다. 그 결과는 제공된에 대한 출력이다.

인수:

쿼리를 실행하는데 사용될 수 있는 명명된 데이타소스들을 검색하는데 사용되는.

이는 쿼리를 실행하는데 사용될 수 있는 임의의 런타임 파라미터들을 포함할 것이다.

results;

이 쿼리의 결과가 기록되는.

5. 커맨드:

인수:

파라미터를 통해 리졸브될 컨텍스트 문서의 URI.

이는 쿼리를 실행하는데 필요한 임의의 런타임 파라미터들을 포함할 것이다.

Results;

이 쿼리의 결과들이 기록되는,, 또는.

6. 커맨드:

설명: 이 실행 메소드는 주어진에 런타임 파라미터로서 쿼리를 제공된상에서 실행한다. 그 결과는에 의해 반환된다. 쿼리의 결과들을 반환하는를 반환한다.

인수:

리졸버에 의해 리졸브되는 디폴트 문서.

7. 커맨드:

설명: 이 실행 메소드는 런타임 파라미터로서 주어진상에서 주어진를 가지고 쿼리를 실행한다. 그 결과는 제공된에 의해 반환된다. 이 오버로드는 업데이트되어대를 취할 때 실행되도록 한다. 쿼리의 결과들을 반환하는를 반환한다.

인수:

리졸버에 의해 리졸브되는 디폴트 문서.

8. 커맨드:

설명: 이 실행 메소드는를 통해에 액세스하고에 의해 제공된 런타임 파라미터들을 이용하여 쿼리를 실행한다. 그 결과들은에 의해 반환된다.

인수:

9. 커맨드:

설명: 이 메소드는를 통해에 액세스하고에 의해 제공된 런타임 파라미터들을 이용하여 쿼리를 실행한다. 디폴트 문서가 제공된 이름을 가지고로 매핑될 수 있다. 그 결과들은에 의해 반환된다.

인수:

리졸버에 의해 리졸브되는 컨텍스트 문서의 URI.

10. 커맨드:

설명: 이 메소드는 주어진 런타임 파라미터로서및 원하는 입력 소스로서를 가지고 쿼리를 실행한다. 결과들이 출력된다.

인수:

원하는 입력들에 대한 데이타소스들을 반환하는.

원하는 출력들에 대한 데이타소스들을 반환하는.

VI. 쿼리 이벤트 메세지

1. 커맨드:

설명: 대역외 정보를 사용자에게 전달할 수 잇는 실행 런타임으로부터 메세지.

이상 설명한 바와 같이, 본 발명의 예시적인 실시예들이 다양한 컴퓨팅 장치들과 네트워크 아키텍쳐들과 관련하여 기술되었지만, 그 아래에 놓인 개념들은 쿼리 시스템 및 애플리케이션 프로그래밍 인터페이스를 구현하기 원하는 임의의 컴퓨팅 장치나 시스템에 적용될 수 있다. 따라서, 본 발명의 방법과 시스템들은 다양한 애플리케이션과 장치들에 적용될 수 있다. 예시적인 프로그래밍 언어, 명칭, 예들이 본 명세서에 다양한 선택 사항들 중 대표적인 것으로 선태되었지만, 이들 언어, 명칭, 예들은 제한적인 것으로 해석되어서는 안된다. 본 기술분야에서 통상의 지식을 가지고 있는 자라면 본 발명에 의해서 달성되는 동일, 유사한, 또는 동등한 시스템들과 방법들을 달성하는 오브젝트 코드를 제공하는 많은 방법들이 있다는 것을 이해할 것이다.

본 명세서의 다양한 기술들이 하드웨어나 소프트웨어, 적절하다면, 그들의 조합으로 구현될 수 있다. 따라서, 본 발명의 방법 및 장치, 또는 그들의 임의의 측면들이나 부분들은 프로그램 코드(즉, 명령어)의 형태로, 플로피 디스켓, CD-ROM, 하드 드라이브, 또는 임의의 다른 기계 판독가능한 저장 매체 등 유형의 매체로 구현될 수 있으며, 여기서, 프로그램 코드가 컴퓨터 등의 기계로 로딩되고 기계에 의해 실행될 때, 이 기계는 본 발명을 실시하기 위한 장치가 된다. 프로그램가능한 컴퓨터 상에서 프로그램 코드가 실행되는 경우에, 이 컴퓨팅 장치는 일반적으로 프로세서, 프로세서에 의해 판독가능한 저장매체(휘발성 및 불휘발성 및/또는 저장 소자), 적어도 하나의 입력 장치, 및 적어도 하나의 출력 장치를 포함할 것이다. 예컨대, 데이타 처리 API 등의 이용을 통하여, 본 발명의 신호 처리 서비스를 이용할 수 있는 하나 이상의 프로그램들은 바람직하게는 높은 수준의 절차적 또는 객체 지향적 프로그래밍 언어로 구현되어 컴퓨터와 통신한다. 그러나, 이 프로그램(들)은 원한다면 어셈블리 또는 기계 언어로 구현될 수 있다. 임의의 경우에, 이 언어는 컴파일된 또는 해석된 언어가 될 수 있고, 하드웨어 구현과 결합될 수 있다.

본 발명의 방법들과 장치는 또한 전선이나 케이블링과 같은 일부 전송 매체 상에서, 광섬유를 통해 또는 임의의 다른 전송 형태를 통해 송신되는 프로그램 코드 형태로 구현되는 통신을 통해 실행될 수도 있는데, 여기서, 프로그램 코드가 수신되고 기계로 로딩되고 기계에 의해 실행될 때, EPROM, 게이트 어레이, 프로그램가능한 논리 장치(PLD: programmable logic device), 클라이언트 컴퓨터, 비디오 리코더 등, 또는 이상의 예시적인 실시예들에 기술된 신호 처리 능력을 갖는 수신 기계와 같은 것들이 본 발명을 실시하기 위한 장치가 된다. 범용 프로세서에서 실시될 때, 이 프로그램 코드는 프로세서와 결합하여 본 발명의 기능을 발휘하도록 동작하는 유일한 장치를 제공한다. 또한, 본 발명과 관련하여 사용되는 임의의 저장 기술들은 일정하게 하드웨어와 소프트웨어의 조합이 될 수 있다.

본 발명이 다양한 도면들의 바람직한 실시예와 관련하여 기술되었지만, 유사한 다른 실시예들이 사용되거나 이 기재된 실시예들에 본 발명과 동일한 기능을 수행하기 위해 본 발명을 벗어나지 않고 변경과 추가가 만들어질 수 있다는 것이 이해될 것이다. 또한, 휴대용 장치 오퍼레이팅 시스템 및 다른 애플리케이션 특정 오퍼레이팅 시스템을 포함하는 다양한 컴퓨터 플랫폼들이, 특히, 무선 네트워킹된 장치들의 수가 계속 증가함에 따라, 고안될 수 있다는 것이 중요하다. 따라서, 본 발명은 임의의 하나의 실시예에 제한되는 것이 아니라, 첨부된 청구항들에 따른 범위와 범주에서 고안되어야 한다.

XML 쿼리와 XML과 비XML 데이타 소스 상에서 XML 쿼리들과 뷰들에 대해 가상 XML을 구현하기 위한 통합적인 표현과 단일 시스템 아키텍쳐를 제공한다.

Claims

실행가능한 쿼리들(queries)을 구성하기 위한 시스템에서, 애플리케이션과 통신하는 방법으로서,

상기 시스템이 상기 애플리케이션으로부터, 하나 이상의 컴파일 파라미터를 설정하기 위한 하나 이상의 콜(call)과 하나 이상의 입력 쿼리를 XML 중간 언어(XML intermediate language) 표현으로 변환하기 위한 커맨드들을 수신하는 단계; 및

상기 시스템이 상기 애플리케이션으로부터, 상기 XML 중간 언어 표현을 실행가능한 쿼리로 변환하기 위한 하나 이상의 콜을 수신하는 단계

를 포함하는 방법.
제1항에 있어서,

상기 애플리케이션이 상기 시스템으로부터, 이벤트 상태, 진행 상태, 중간 결과, 최종 결과들, 에러 메세지들, 경고 및 도움말 메세지를 포함하는 그룹 중 하나 이상을 수신하는 단계를 더 포함하는 방법.
제1항에 있어서,

하나 이상의 환경, 컴파일 파라미터들 및 컴파일 커맨드들을 설정하기 위한 상기 하나 이상의 콜은 상기 시스템으로부터 메세지 수신을 가능하게 하는 것, 쿼리 허가 및 실행 제한을 특정하는 것, 입력 쿼리 및 컴파일러 형식을 선택하는 것, 및 평가 컨텍스트들(contexts)를 확립하는 것 중 하나 이상을 포함하는 방법.
제3항에 있어서,

상기 컴파일러 형식은 XPath, XSLT 및 XQuery 언어 컴파일러들을 포함하는 방법.
제1항에 있어서,

상기 XML 중간 언어 표현은 입력 쿼리의 의미론적인 표현(semantic representation)인 방법.
제1항에 있어서,

상기 XML 중간 언어를 상기 실행가능한 쿼리로 변환하는 단계는 타겟 쿼리 실행 엔진에서 직접 실행하기 위한 XML 중간 언어를 준비하는 단계를 포함하는 방법.
제1항에 있어서,

상기 XML 중간 언어를 상기 실행가능한 쿼리로 변환하는 단계는 타겟 생성기를 사용하여 상기 XML 중간 언어를 타겟 표현으로 변환하는 단계를 포함하는 방법.
제7항에 있어서,

상기 타겟 표현은 XML 언어 타겟, SQL 언어 타겟 및 중간 언어 타겟을 포함하는 그룹 중 하나 이상인 방법.
애플리케이션과 통신하기 위하여 제1항의 방법을 이용하여 실행가능한 쿼리들을 구성하기 위한 시스템.
쿼리 결과들을 생성하는 입력 쿼리들을 컴파일 및 실행하기 위한 시스템에 있어서,

입력 쿼리를 수신하기 위한 입력 장치;

하나 이상의 중간 언어 컴파일러 - 상기 입력 쿼리로부터 XML 중간 언어 표현이 컴파일됨 - ;

하나 이상의 타겟 생성기 - 상기 XML 중간 언어 표현은 타겟 쿼리를 형성하는 하나 이상의 타겟 표현으로 변환됨 - ;

쿼링(querying over)을 위한 하나 이상의 데이타 소스; 및

실행 엔진 - 상기 타켓 쿼리는 상기 하나 이상의 데이타 소스 상에서 실행되어 상기 쿼리 결과들을 생성함 -

을 포함하는 시스템.
제10항에 있어서,

상기 입력 쿼리는 XPath, XSLT 및 XQuery 언어들 중 하나 이상으로 형성되는 쿼리를 포함하는 시스템.
제10항에 있어서,

상기 XML 중간 언어 표현은 상기 입력 쿼리의 의미를 표현하는 시스템.
제10항에 있어서,

상기 하나 이상의 타겟 생성기는 XML 언어 생성기, SQL 언어 생성기 및 중간 언어 생성기 중 하나 이상을 포함하는 시스템.
제10항에 있어서,

상기 하나 이상의 데이타 소스는 하나 이상의 관계형(relational) 데이타 소스들 및 비관계형(non-relational) 데이타 소스들 중 하나 이상을 포함하는 시스템.
제14항에 있어서,

상기 비관계형 데이타 소스들은 스프레드시트들과 워드 프로세싱 문서들을 포함하는 시스템.