xml-cdl issues on rev 0.2: discussion, solutions, and proposal of rev 0.3
DESCRIPTION
XML-CDL Issues on Rev 0.2: Discussion, Solutions, and Proposal of Rev 0.3. Jun Tatemura NEC Laboratories America July 27, 2004. Issues Overview. Reference Model Clarification of two reference models: value references (ref/refroot) and prototype references (extends) Schema (how to use) - PowerPoint PPT PresentationTRANSCRIPT
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”