Re: Hierachy constraining facets

Just to clarify - I don't think we should give the impression that
we are immediately adopting this as a requirement for version 2.

Indeed, when the list facility was added at a late stage to version 1,
it was with the understanding that it would be kept very simple and
not be the start down a slippery slope of increasing complexity.
There is a point of view that XML primarily offers elements for
marking up and constraining structured information.

Thanks,

  David

Ashok Malhotra wrote:
> 
> 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 23:47:29 UTC