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

1. XML-CDL Issues on Rev 0.2:Discussion, Solutions, and Proposal of Rev 0.3 Jun Tatemura NEC 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) (2) (1) (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) (2) (1) b (3) b b b a a a a 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. Resolution of extends ? Relative path

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:name / cdl:extends cdl:ref cdl:refroot 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> <b>20</b> <d cdl:ref=“/b”/> </c> </a> <a cdl:name=“a”> <b>10</b> <c cdl:name=“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 cdl:extends=“ns1:Apache” /> … </cdl:configuration> <cdl:configuration> <Apache… /> <Tomcat…/> … </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:refroot cdl:configuration refroot=“c” / a b c f g h j “/a/d” or “.” d e “/e” or ”../e” k l @ref “/a/d/l” or “l”

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” not allowed refroot + xpath cdl:ref=“xpath”

15. Translation from CDL-1 to CDL-0 • Translation of extension references disallowed in CDL-0 @cdl:extends @cdl:extends @cdl:name @cdl:name @cdl:extends @cdl:extends @cdl:extends No relative Paths to outside CDL-1 (rev 0.2) CDL-0 (rev 0.3)

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 refers-to refers-to input A CDL processor may optionally generate an XSD for resolved configuration data CDL processor output CDL XSD validates

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”: e a reference b c d f b c d d insert

24. e f d b c a e b c d b c d e g f d b c d Current Issue • Neither @cdl:extends or @cdl:ref cannot do it @extends e f d @ref e f d e f d g @ref

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. Lifecycle manager Laziness resolution @lazy config data CDL Prototype resolution Reference resolution CDL extractor XSD @extends @ref

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 refroot=“b” / a b “/c” or “..” c d e f “/c/g” or “.” “/d” or ”../../d” refroot=“b” ref=“/e” g h “/c/h” or ”../h” j @ref i “/c/g/j” or “j” k “/c/g/j/k” or “j/k”

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. a b: {e,f} c i j g: … h: … k: … l: … m: … n: … 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 d a b c d e f g h i j Resolved CDL k l m n Component 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”