IPDR Protocol Working Group Status Update

Objective

The IPDR Protocol Working group will define:

Syntax, structure and format for formal services and attributes definition
Transport protocol for IPDR XML text encoding
The IPDR Protocol group will continuously interact with BSS group on services and attribute definition.

Working Plan

1.      Formal service definition: Syntax, Encoding, Naming Conventions, etc.    - due 5/15/2000
2.      Attribute alignment: common attributes, service-dependant attributes, etc.        - due 6/15/2000
3.      Define transport protocol for IPDR XML text encoding - due 7/15/2000
4.      Improve and clarify naming and global-local uniqueness mechanisms - due 9/15/2000
5.      Consider usage of the XMLSchema as a formal definition language for IPDRDoc structure       - on-going activity
6.      IPDR Binary encoding and transport      (optional) - due 10/15/2000
7.      IPDR API abstract model and recommendations (optional) - due 10/15/2000

Service Definition

1. IPDR Service Definitions are XML Schema documents.

2. Service Definitions define only a subset of a full IPDR schema. Specifically, they define the elements/attributes particular to individual service definitions.

3. The IPDR base schema must be defined (as a schema document) and available for reference by Service Definitions.

4. A Service Definition is identified by its canonical schema location. i.e., ipdr.org/video/VideoOnDemand1.xsd, foo.com/phone2.xsd

ISSUE: better to have identifier not tied to location.how to do this??

5. The IPDR Service Definition defines Usage Attributes as Elements. Usage Attributes are identified by "name" attributes on the <v> element in IPDR 1.0. This will change in a later version of IPDR, once schema-validating parsers become available.

6. A Service Definitions MUST supply a

element definition. This contains one or more element definitions.

7. Each Usage Attribute element definition MUST provide a name and a type.

8. The types used MAY be defined by XML Schema Part 2, or MAY be defined locally.

9. Usage Attribute names MUST NOT be repeated within the UE definition.

10. Usage Attribute definitions MAY supply a minOccurs="0|1" to specify whether the Usage Attribute is required or optional.

11. Usage Attributes MAY specify default values by using default="foo" attribute.

12. Schemas may include other schemas by using one or more <include schemaLocation="http://www..."/>

13. XML Schema's <annotation><documentation> elements MUST be used to describe each Usage Attribute definition. They appear within the <element> definition.

Attribute Alignment

Attribute naming convention for mixed case, initial lower case. e.g. movieName, not movie_name or MovieName.

Producing a baseline Common Service definition above will address this requirement.

Transport Protocol

XML over HTTP based approach is focus of current work.

To avoid duplication of existing industry work in carrying XML over HTTP, the SOAP specification was chosen.

Issues

Lack of tools and established conventions for use with XML Schema.

The model developing is to compose an IPDR document from a set of XML Schema definitions (minimally one for the IPDR Document, one for the common Service attributes and one for the specific service carried in a given document). Composition makes the extensibility of IPDR to include new services a matter of publishing a new schema for the new service in question.

The mechanisms provided for performing composition include:

namespace reference (xmlns:)
include operations (used as part of a schema definition itself)
import operations (used as part of schema definition)
xsi:schemaLocation attributes

How schema validation is actually performed, in terms of how the a validating parser determines the final schema to apply for validation, is left quite open by the XML Schema specification:

"Processors on the Web are free to assess schema-validity against arbitrary schemas in any of the ways set out in Schema Validation of Documents" XML Schema 1 - Section 6.3.2

and

"The means used to locate appropriate schema document(s) are processor and application dependent" XML Schema 1 - Section 6.3.2

Section 6.3.2 then goes on to recommend the use of the xsi:schemaLocation as the basic way to pass information onto a validating parser.

As an example: