Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 XML-CDL Issues on Rev 0.2: Discussion, Solutions, and Proposal of Rev 0.3 Jun Tatemura NEC Laboratories America July 27, 2004.

Similar presentations


Presentation on theme: "1 XML-CDL Issues on Rev 0.2: Discussion, Solutions, and Proposal of Rev 0.3 Jun Tatemura NEC Laboratories America July 27, 2004."— Presentation transcript:

1 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 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 3 Reference Model

4 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 ns1ns2ns3 cdl:extends (prototype reference) cdl:ref (value reference)

5 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 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 a b aa b a b a

7 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 Resolution of extends

8 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 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 10 Issues in the Current Approach Often redundant (awkward) Inserting @cdl:name can change the destination of @cdl:ref (error prone) 10 20 10 20

11 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 ) may be prototypes Children of must be unique … … ns1

12 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 abc de fghj kl @ref / “ /e ” or ”../e ” “ /a/d/l ” or “ l ” “ /a/d ” or “. ” refroot= “ c ”

13 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 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 ns1ns2ns3 abacbd cdl:extends= “ ns1:a ” cdl:ref= “ xpath ” / not allowed refroot + xpath

15 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 relative Paths to outside @cdl:name @cdl:extends

16 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 ”

17 17 Schema

18 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 19 XML Schema for Result Validation Is XML Schema applied to validate resolved configuration data? CDL XSD CDL processor CDLXSD validates refers-to input output A CDL processor may optionally generate an XSD for resolved configuration data

20 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)

21 21 Example of Validation After reference resolution v1 v3 A CDL processor may generate Configuration data v1 v3 XSD for the configuration data …

22 22 Extension of Lists

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

24 24 Current Issue Neither @cdl:extends or @cdl:ref cannot do it e fd a bcd e fd e fd @extends @ref g e fd bc bcd e e fd g bcd

25 25 Introducing a New Element: cdl:ref cdl:insert v1 v2 v3 v4 v5 Is resolved to: v4 v1 v2 v3 v5

26 26 Then, what about @cdl:ref? @cdl:ref Is a short form of: Although functionality is redundant, we keep this @cdl:ref in the spec for convenience

27 27 Lazy References

28 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 29 Use of @cdl:lazy We may put @lazy at producer side Or consumer side (i.e., @ref) 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 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: Is resolved to: 100 Example 2: Is resolved to: (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 31 Path Expression for Value References

32 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 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 * @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 34 Miscellaneous Issues

35 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 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 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 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 39 XML-CDL Rev 0.3

40 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 41 Language Processing Resolutions: Prototype resolution Reference resolution Laziness resolution Those resolutions are defined as transformation of trees

42 42 Language Processing Model Note that it is not meant to specify an implementation architecture. Prototype resolution Reference resolution Laziness resolution @extends@ref @lazy CDL extractor config data XSD Lifecycle manager

43 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 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 Replace the node cdl:insert with children of n Insert children of n as children of a Reference Resolution: repeat resolution of a resolvable reference until there is no resolvable reference.

45 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 46 XPath Examples cdl:configuration ab gh cef i j @ref / “ /c/h ” or ”../h ” “ /c/g/j ” or “ j ” “ /c/g ” or “. ” refroot= “ b ” ref= “ /e ” k “ /c/g/j/k ” or “ j/k ” d “ /d ” or ”../../d ” “ /c ” or “.. ”

47 47 Expression A special type of value references <cdl:variable name= “ xsd:NCName ” refroot= “ xsd:QName ” ref= “ cdl:pathType ” />* 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 48 Laziness Resolution A laziness resolution Removal of one or more @cdl:lazy attribute, possibly with value insertions Insert a value into the node a Remove the @cdl:lazy attribute 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 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 klmn g a b: {e,f} c g: … h: … d i k: … l: … j m: … n: … Resolved CDL Component structure

50 50 CDL Data Structure CDL Document * ? { ? templateType}* ? ? templateType * CDL Notations (global attributes) @cdl:ref= “ xpath ”, @cdl:refroot= “ QName ” @cdl:extends= “ QName ” @cdl:use = (optional | required), @cdl:type= “ QName ” @cdl:lazy= “ boolean ”


Download ppt "1 XML-CDL Issues on Rev 0.2: Discussion, Solutions, and Proposal of Rev 0.3 Jun Tatemura NEC Laboratories America July 27, 2004."

Similar presentations


Ads by Google