1 xml-cdl issues on rev 0.2: discussion, solutions, and proposal of rev 0.3 jun tatemura nec...

1

XML-CDL Issues on Rev 0.2:Discussion, Solutions, and Proposal of Rev 0.3

Jun TatemuraNEC Laboratories America

July 27, 2004

2

Issues Overview Reference Model

Clarification of two reference models: value references (ref/refroot) and prototype references (extends)

Schema (how to use) How we should validate (1) CDL documents

(2) resolved configuration data Miscellaneous issues

Extension of lists, Lazy references, XPath, etc

3

Reference Model

4

CDL model CDL is a tree References between nodes

Prototype references (extends) Value references (ref)

Resolution of references: transformation operations applied to the tree

ns1 ns2 ns3

cdl:extends (prototype reference)cdl:ref (value reference)

5

Resolution of Prototype References Resolution of prototype references (cdl:extends) is done before resolution of value references (cdl:ref) Cascaded resolution: to resolve (1)

(2) must be resolved (3) must be resolved (if (3) is a relative path)

(1)(2)

(3)

6

Resolution of Value References Resolution of value references (cdl:ref) is done after resolution of

prototype references (cdl:extends) To resolve (1)

(2) and (3) must be resolved (if they are relative paths)

(1)(2)(3) b

ab

a a

b

a

b

a

7

Problem in Integrated Resolution The destination of @cdl:extends has a relative path @cdl:ref in its descendant. Resolution of prototype may generate a value reference to an unexpected

destination.

?

Relative path

Resolutionof extends

8

Possible Solutions (1) don’t care or runtime error/alert (SF-CDL?) (2) runtime translation of relative paths (complicated…) (3) limit destinations of references

(3-1) limit destinations of cdl:extends to nodes with cdl:name and use cdl:refroot (XML-CDL rev 0.2) (3-2) limit destinations of cdl:extends to top level nodes and use cdl:refroot (rev 0.3 proposal)

a relative path to outside

9

Current Solution in XML-CDL Rev 0.2 The destination of “cdl:extends” must be predefined with “cdl:name” “cdl:name” is a document root for “cdl:ref” (a relative path to outside is avoided) “cdl:refroot” is used to refer outside: a path can be copied to anywhere (an

absolute path)

cdl:name/

cdl:refrootcdl:ref

cdl:name

cdl:extends

copy

10

Issues in the Current Approach Often redundant (awkward)

<apache cdl:name=“apache” …/> Inserting @cdl:name can change the

destination of @cdl:ref (error prone)

<a cdl:name=“a”> <b>10</b> <c cdl:name=“c”> <b>20</b> <d cdl:ref=“/b”/> </c></a>

<a cdl:name=“a”> <b>10</b> <c> <b>20</b> <d cdl:ref=“/b”/> </c></a>

11

Proposal in Rev 0.3 [1] Remove “cdl:name” Limit the destination to a top level node

Only top level property lists (children of <cdl:configuration>) may be prototypes

Children of <cdl:configuration> must be unique

<cdl:configuration> <Apache … /> <Tomcat …/>…</cdl:configuration>

<cdl:configuration> <Apache cdl:extends=“ns1:Apache” />…</cdl:configuration>

ns1

12

Proposal in Rev 0.3 [2] “cdl:ref” and “cdl:refroot”

Same as Rev 0.2 Root is the top level node specified

with cdl:refrootcdl:configuration

a b c

d ef g h j

k l@ref

/

“/ e” or ”../e”

“/a/d/l” or “l”

“/a/d” or “.”

refroot=“c”

13

Classes of CDL Models CDL-1: SF-CDL, XML-CDL rev 0.2

Any node can be the destination of a prototype reference

CDL-0: XML-CDL rev 0.3 Only top level nodes can be the destination

of a prototype reference Subset of CDL-1

An instance of CDL-0 is also an instance of CDL-1 CDL-1 can be translated to CDL-0 (discussed

later) SF-CDL can be translated to XML-CDL rev 0.3

14

CDL Model CDL-0 A template is a child of cdl:configuration cdl:extends refers to a template Relative path in cdl:ref is local within a template

ns1 ns2 ns3

a b a c b d

cdl:extends=“ns1:a”cdl:ref=“xpath”

/

not allowed refroot + xpath

15

Translation from CDL-1 to CDL-0 Translation of extension references

disallowed in CDL-0

CDL-1 (rev 0.2) CDL-0 (rev 0.3)

No relativePaths to outside

@cdl:name

@cdl:name

@cdl:extends

@cdl:extends

@cdl:extends

@cdl:extends

@cdl:extends

16

Benefits Cleaner semantics

awkward errors avoided, more modularity in templates, simpler implementation

Reduce of descriptive power does not seem significant

Extensible to CDL-1 If we really need CDL-1, XML-CDL ver 1.x can later

introduce (with retaining backward compatibility) @cdl:extends=“xpath”

<ns2:d cdl:extends=“ns1:a/b” />

17

Schema

18

XML Schema for CDL Validation Is XML Schema applied to validate CDL documents?

Issue is that a CDL document contains incomplete configuration data for which no predefined schema is given

Discussion Agree with [Steve] “It is essentially impossible for a non-

lax parser to parse CDL files where any of the attributes are not defined in a schema.”

Once a lax parser parse a CDL document, a CDL processor may be able to generate an XSD specific to this CDL document so that a non-lax parser can parse it …

Alternatively, when a tool generates a CDL document, it may be able to generate an XSD for the document, too.

Those XSD files are correlated to namespace names using cdl:import

19

XML Schema for Result Validation Is XML Schema applied to validate

resolved configuration data?

CDL CDL XSD

CDL processor

CDL XSDvalidates

refers-torefers-to

input

output

A CDL processor may optionally generate an XSD for resolved configuration data

20

@cdl:type Attribute for Type Annotation @cdl:type=“qname” Light weight approach for type specification A type can be defined either externally (cdl:import) or internally (the cdl:types) Useful for result validation Resolved data can be validated with @cdl:type (type check) and @cdl:use

(optionality check)

<cdl:configuration> <WebServer> <hostname cdl:type=“xsd:string”/> <port cdl:type=“xsd:int”/> </WebServder></cdl:configuration>

21

Example of Validation After reference resolution

<a> <a1 cdl:type=“t1” cdl:use=“required”>v1</a1> <a2 cdl:type=“t2” cdl:use=“optional” /> <a3 cdl:type=“t3” cdl:use=“optional” >v3</a3></a>

A CDL processor may generate Configuration data

<a><a1>v1</a1><a2/><a3>v3</a3></a> XSD for the configuration data

<xsd:complexType name=“aType”><sequence><element name=“a1” type=“t1”…> …</sequence></xsd:complexType>

22

Extension of Lists

23

Extension of Lists SF-CDL can extend (import and concatenate) a list In the tree model, this is “insertion”:

ea

b c db c df d

reference

insert

24

Current Issue Neither @cdl:extends or @cdl:ref cannot do it

e

f da

b c d e

f d

e

f d

@extends

@ref

g@ref

e

f db c

b c d

e

e

f dg

b c d

25

Introducing a New Element: cdl:ref

cdl:insert<a><b>v1</b><c>v2</c><d>v3</d></a><e> <f>v4</f> <cdl:ref ref=“/a”/> <d>v5</d></e>Is resolved to:<e> <f>v4</f> <b>v1</b><c>v2</c><d>v3</d> <d>v5</d></e>

26

Then, what about @cdl:ref? @cdl:ref

<a cdl:ref=“path” />Is a short form of:<a><cdl:ref ref=“../path”/></a>

Although functionality is redundant, we keep this @cdl:ref in the spec for convenience

27

Lazy References

28

Lazy It is desirable to have consumer-side

specification of lazy resolution (just as SmartFrog)

Rev 0.2@cdl:mode = (optional | required | automatic)

Rev 0.3@cdl:use = (optional | required)@cdl:lazy = “xsd:boolean”- @mode has been clearly split to schema

annotation (@use) and laziness annotation (@lazy)

29

Use of @cdl:lazy We may put @lazy at producer side

<a cdl:lazy=“true” cdl:type=“xsd:int”/> Or consumer side (i.e., @ref)

<b cdl:ref=“path” cdl:lazy=“true”/> <cdl:insert ref=“path” lazy=“true”/>

Semantics A reference that has @cdl:lazy attribute either at

source or destination must not be resolved until @cdl:lazy is resolved

Resplution A lifecycle policy (out of scope) decides when a

@cdl:lazy attribute is resolved.

30

Lifecycle Policy A dynamic value is fixed at runtime. The timing depends on a

lifecycle model/policy From CDL’s viewpoint, it is represented as “@lazy resolution”

Example 1:<a cdl:lazy=“true”/>Is resolved to:<a>100</a>Example 2:<a cdl:ref=“xxx” cdl:lazy=“true”/>Is resolved to:<a cdl:ref=“xxx”/> (now it becomes a resolvable reference)

@lazy resolution may generate resolvable references After each @lazy resolution, @ref resolution will be applied Hence, a lifecycle policy has control over timings of lazy

reference resolution

31

Path Expression for Value References

32

XPath: Reference or Function? XPath may be too expressive:

Harmful rather than useful A path can refer to cdl attributes A path can work as functions,...

Discussion on use of XPath functions:[Steve] Functions. Does it make sense for references to

include string and number functions? These are no longer real references, so much as value evaluation operations.

A best practice in XML Schema specification: Define a subset of XPath

33

Use of Two XPath Subsets @cdl:ref=XPath

@ref may have only a subset of location path patterns (self, child, and parent axes; qname node tests; no predicate). Functions are defined differently.

Path ::= (‘/’)? Step (‘/’ Step)*Step ::= ‘.’|’..’| QName

Functions<cdl:insert value-of=“xpath”> <cdl:param name=“NCName” refroot=“QName”?

ref=“xpath”/>*</cdl:insert> @value-of=“xpath” is an XPath expression which does

not include location path patterns (all values come from variables defined with cdl:param elements)

34

Miscellaneous Issues

35

Changes @cdl:mode=“automatic”

Renamed to @cdl:lazy cdl:import and cdl:include

consolidated to cdl:import Now it can import either xsd or cdl (just like wsdl:import)

/cdl:cdl/@pathLanguage Removed (later version may add this) path expression MUST be XPath 1.0

cdl:documentation Added for documentation insertion

cdl:component Removed since component semantics will be given by the

component model

36

Questions and Answers[Steve] Standard CDL Attributes: We are going to need standard

attributes, with names such as “host” and “policy”. These should all be declared and typed and placed into the cdl: namespace, or one for standard attributes.

[Jun] These attribute definitions must be Kojo’s “basic profile”, which is a standard vocabulary for a specific domain. This must be defined separately from CDL itself. Hence the namespace for these must not be cdl.

[Steve] Designing for extensibility?[Jun] Yes. CDL elements must permit attributes and elements of

external schema in order to incorporate, for example, external lifecycle models (or policies).

[Steve] What is our future plan for versioning the schema?[Jun] Each version of CDL should have its own namespace. OASIS

has its own naming scheme of namespaces. I am wondering how about one in GGF.

37

Discussions[Steve] Binding to System Properties. Proposal: (1) There is a system

component whose attributes are those of the running machine. OS-specific properties (temp dir, file separator, etc, will be exported well known names) runtime/system/temp.dir (2) There is another system component whose attributes represent that of an optional list of (name,value) settings supplied to the runtime during deployment. (3) The name value pairs are supplied in deployment API specific forms. For the SOAP deployment API, this list can be a set of XML name/value assignments. For Java it could be on the command line. For .NET, well, there are ini files

[Jun] I may not understand your proposal correctly. My understanding is that those system properties must be exposed as XML views. XML-CDL can refer to any system property with @refroot and @ref. Schema of an XML view of a specific system property must be predefined. Some schema may be standardized in “basic profile,” outside of CDL language specification.

38

Discussions[Steve] Processing Instructions. We need a policy on PI

declarations. I nominate the SOAP one: none are allowed

[Jun] I am not sure we need a policy on PI declarations. For example, WSDL 1.1 specification is silent about PI. SOAP needed to mention about PI because of SOAP intermediary issues. If there will be no specific problem on PI, we can keep silent. What would be our problem on PI?

39

XML-CDL Rev 0.3

40

CDL Data Model A template is a tree

Template name: each template has a unique QName A template is an incomplete configuration data structure

with CDL notations inserted A CDL document is a forest of trees (set of

templates) References: prototype reference (@cdl:extends=

template name), value reference (@cdl:refroot= template name, @cdl:ref = XPath)

Value insertion: cdl:ref, expression: cdl:expression Annotations: Laziness annotation (@cdl:lazy),

Schema annotation (@cdl:use, @cdl:type)

41

Language Processing Resolutions:

Prototype resolution Reference resolution Laziness resolution

Those resolutions are defined as transformation of trees

42

Language Processing Model Note that it is not meant to specify an

implementation architecture.

Prototyperesolution

Referenceresolution

Lazinessresolution

@extends @ref

@lazy

CDL CDL extractor

configdata

XSD

Lifecyclemanager

43

Prototype Resolution Prototype reference

@cdl:extends=“qname” at any node qname is the name of the destination template

Resolvable reference A reference is resolvable if and only if:

The root node of the destination template does not have @cdl:extends attribute

Resolution of a reference Inheritance of children Inheritance of cdl schema annotations (@cdl:use,@cdl:type) Removal of @cdl:extends attribute

Prototype Resolution Repeat resolution of a resolvable reference until there is no

resolvable reference

44

Reference Resolution Value reference

[@cdl:refroot=“qname”? @cdl:ref=“xpath”] at any leaf node Resolvable reference

A reference is resolvable if and only if: XPath evaluation returns a node n n and its descendants do not have @ref or @lazy

Resolution of a resolvable reference <cdl:ref ref=“xpath” />

Replace the node cdl:insert with children of n <a cdl:ref=“xpath”/>

Insert children of n as children of a Reference Resolution: repeat resolution of a

resolvable reference until there is no resolvable reference.

45

XPath Evaluation Reference at a node n (n/@cdl:ref=“xpath”)

If n has @cdl:refroot=“qname” attribute Root node(/): the root of the template identified with qname Context node(.): equals the root node

Else Root node (/): the root of the template that contains the

node n. Context node (.): the parent of the node n.

XPath Expression: a subset of XPath 1.0 location path patterns (cdl:pathType):

Restriction: Axes are only self, child, or parent Node tests are only qnames No predicates

46

XPath Examples

cdl:configuration

a b

g h

c e f

i j@ref

/

“/ c/h” or ”../h”

“/c/g/j” or “j”

“/c/g” or “.”

refroot=“b”

refroot=“b”ref=“/e”

k“/c/g/j/k” or “j/k”

d

“/ d” or ”../../d”

“/c” or “..”

47

Expression A special type of value references

<cdl:expression value-of=“cdl:exprType”> <cdl:variable name=“xsd:NCName” refroot=“xsd:QName” ref=“cdl:pathType”/>*</cdl:expression>

Cdl:exprType: a subset of XPath Restriction: (1) a location path must not be

included (2) must return either a boolean, number, or string value

A cdl:variable element binds a property value to a variable name

48

Laziness Resolution A laziness resolution

Removal of one or more @cdl:lazy attribute, possibly with value insertions

<a cdl:lazy=“true”/> Insert a value into the node a Remove the @cdl:lazy attribute

<a cdl:lazy=“true” cdl:ref=“xpath”/> Remove the @cdl:lazy attribute

Selection of @cdl:lazy attributes and values depends on implementation

After a laziness resolution, a reference resolution is applied

49

Extraction of Configuration Data Application specific data structure is

overlaid on the CDL (resolved) tree CDDLM Basic Services/Component Model

Component structure will be extracted

a

dcb

jihfe

k l m n

g

ab: {e,f}

cg: …h: …

d

ik: …l: …

jm: …n: …Resolved

CDLComponent structure

50

CDL Data Structure CDL Document

<cdl targetNamespace=“xsd:anyURI”?> <import namespace=“xsd:anyURI”?

location=“xsd:anyURI”/>* <types />? <configuration>{<documentation/>? templateType}*</>? <system><documentation/>? templateType</>*</cdl>

CDL Notations (global attributes) @cdl:ref=“xpath”, @cdl:refroot=“QName” @cdl:extends=“QName” @cdl:use = (optional | required), @cdl:type=“QName” @cdl:lazy=“boolean”