RE: Hierachy constraining facets

I agree that we need to consider complex list facilities and
I agree that we may well reject them infavor of more explicit
XML syntax based markup. May I suggest we consider it a
canidate requirement.

Regards,
Dave Hollander

> -----Original Message-----
> From: www-xml-schema-comments-request@w3.org
> [mailto:www-xml-schema-comments-request@w3.org]On Behalf Of 
> David Beech
> Sent: Monday, December 04, 2000 10:58 AM
> To: Ashok Malhotra
> Cc: PNiederau2@heyde.de; www-xml-schema-comments@w3.org
> Subject: 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 Tuesday, 5 December 2000 19:36:56 UTC