- From: Ashok Malhotra <petsa@us.ibm.com>
- Date: Mon, 4 Dec 2000 09:00:59 -0500
- To: PNiederau2@heyde.de
- Cc: www-xml-schema-comments@w3.org
This is an interesting idea but it comes late in the day. I suggest we take this as a requirement for version 2. All the best, Ashok PNiederau2@heyde.de@w3.org on 11/20/2000 10:57:55 AM Sent by: www-xml-schema-comments-request@w3.org To: www-xml-schema-comments@w3.org cc: Subject: Hierachy constraining facets Dear colleagues, I would like to propose an additional constraining facet for list types. Consider for example that you want to use a list of string values for storing the full path of a file or the name of a Java package, e. g. you define the following type in a XML schema <simpleType name="package"> <list itemType="string"> </simpleType> and use it as follows in an XML document: <aPackage type="package">org jdom input<aPackage/> as a representation for org.jdom.input. It is useful to restrict the values of "package" to the existing packages. E. g. you can do that by using the enumeration constraining facet: <simpleType name="packages"> <restriction> <simpleType> <list itemType="string"> </simpleType> <enumeration value="org"/> <enumeration value="org jdom"/> <enumeration value="org jdom adapters/"> <enumeration value="org jdom input/"> <enumeration value="org jdom output/"> <enumeration value="org log4j"/> <enumeration value="org log4j examples/"> <enumeration value="org log4j helpers/"> </restriction> </simpleType> The possible values are hierarchically built as in many other examples. It would be nice if you could constrain the values of a list to such a hierarchically structure, i. e. to the paths of a tree. Due to this motivation I propose an additional constraining facet called hierarchy. Let's take a look at an example using this new facet: <simpleType name="packages"> <restriction> <simpleType> <list itemType="string"> </simpleType> <hierarchy value="org"> <hierarchy value="jdom"> <hierarchy value="adapters"/> <hierarchy value="input"/> <hierarchy value="output"/> </hierarchy> <hierarchy value="log4j"> <hierarchy value="examples"/> <hierarchy value="helpers"/> </hierarchy> </hierarchy> </restriction> </simpleType> Instead of the enumeration facet the hierarchy facet is used here. A hierarchy facet has a value attribute like the enumeration facet. In addition, a hierarchy element can contain a number of hierarchy elements as children. The top level hierarchy element constrains the first element of the list. The i-th element of the list is constrained by the hierarchy elements on i+1-st level depending on the first i elements in the list. The hierarchy facet has the advantage that lists can be constrained more specific to a special group of values. All repetitions of common prefixes can be avoided. Implementations can store elements of such lists more efficiently. I tried to embed the hierarchy facet into the XML scheme part 2 in order to give a clear cut definition. I'm looking forward to your comments, Philipp Niederau Heyde AG, Bad Nauheim, Germany ---------------------------------------------------------------------------- ------------------------------- 4.2.16 (new) hierarchy provides for * Constraining a value space of a list to a specified set of values Schema Component: hierarchy [value] A tree called hierarchy where each node contains a value from the value space of the base type definition [annotation] Optional. An annotation. Validation Rule: hierarchy valid A value in a value space if facet-valid with respect on hierarchy if: 1. the value is a path (from the root to any desired leaf or inner node) of the hierarchy {value} A hierarchy is a root node. A node consists of a value combined with i successor nodes (i>=0). A path of a hierarchy is a list with n elements (n>0) where the first element is the value of the root node of the hierarchy and the i+1th element is the value of a successor node of the i-th element in the hierarchy for all 1<=i<n. 5.1.2 (additional) When a datatype is derived from a list datatype, also the hierarchy constraining facet can be used. 5.2.16 (new) The XML representation for a hierarchy schema component is a hierarchy element information item. The correspondences between the properties of the information item and properties the component are as follows: XML Representation Summary: hierarchy Element Information Item <hierarchy id = ID value = string {any attributes with non-schema namespace...} > Content: (annotation?) (hierarchy*) </hierarchy> hierarchy Schema Component {value} A hierarchy which is the root node build up from the hierarchy element item appearing as a child of the simple type. The hierarchy element builds a node where the value of the node is the value of the value item and the successor nodes are the hierarchies build up from the hierarchy elements appearing as children of the hierarchy item. {annotation} The annotation corresponding to the annotation element information item in the children, if present, otherwise null Example 1): Hierarchy <simpleType name="stringList"> <list itemType="string"> </simpleType> <simpleType name="package"> <restriction base="stringList"> <hierarchy value="org"> <hierarchy value="jdom"> <hierarchy value="adapters/"> <hierarchy value="input"/> <hierarchy value="output/"> </hierarchy> <hierarchy value="log4j"> <hierarchy value="examples/"> <hierarchy value="helpers"/> </hierarchy> </hierarchy> </restriction> </simpleType> <aPackage type="package">org jdom input<aPackage/> Example 2): If you want to allow further values at top level you can use a hierarchy element with an empty string value: <simpleType name="packages"> <restriction> <simpleType> <list itemType="string"> </simpleType> <hierarchy value=""> <hierarchy value="org"> <hierarchy value="jdom"> <hierarchy value="adapters"/> <hierarchy value="input"/> <hierarchy value="output"/> </hierarchy> <hierarchy value="log4j"> <hierarchy value="examples"/> <hierarchy value="helpers"/> </hierarchy> </hierarchy> <hierarchy value="com"> <hierarchy value="sun"></hierarchy> <hierarchy> </restriction> </simpleType> It is an open question if it is a good idea to allow empty strings as values for inner nodes. It should also be discussed if multiple hierarchy elements with same values should be allowed as successor nodes for one hierarchy element. Both possibilities would lead to ambiguous paths, i. e. two different paths through the hierarchy can have the same lexical representation. Philipp Niederau Stefan Wachter Heyde AG, Bad Nauheim, Germany
Received on Monday, 4 December 2000 09:01:03 UTC