MSL A model for W3C XML Schema
Allen Brown, Microsoft, [email protected] Matthew Fuchs, Commerce One, [email protected] Jonathan Robie, Software AG, [email protected] Philip Wadler, Avaya Labs, [email protected]
ABSTRACT equate to understand this paper; all other notations are de- MSL (Model Schema Language) is an attempt to formalize fined before they are used. some of the core idea in XML Schema. The benefits of We hope our work on MSL may make XML Schema eas- a formal description is that it is both concise and precise. ier to understand, and may aid in the process of designing MSL has already proved helpful in work on the design of other specifications and tools that build on XML Schema. XML Query. We expect that similar techniques can be used In particular, MSL has already proved helpful in work on the to extend MSL to include most or all of XML Schema. design of XML Query, another W3C standard currently un- der development. We expect that similar techniques can be used to extend MSL to include most or all of XML Schema. 1. INTRODUCTION MSL (like XML Schema) draws on standard ideas about XML is based on two simple ideas: represent documents type systems for semistructured data as described in the and data as trees, and represent the types of documents and literature [1, 9], notably the use of regular expressions and data using tree grammars. Tree grammars are represented tree grammars. In particular, MSL closely resembles the using DTDs [4] or XML Schema [6, 11, 3]. XML Schema type system in Xduce [8]. Another example of formalizing is being developed under the auspices of the World Wide part of an XML specification can be found in [12]. Web Consortium (W3C), the body responsible for HTML Many important aspects of XML Schema are not modeled and XML, among other things. As of this writing, XML by MSL. We have focussed on the core material in XML Schema recently entered candidate recommendation status. Schema Part I (Structures), as we believe this is the most XML Schema is more powerful than DTDs. Among other complex. Many features of XML Schema are not modeled. things, it uses a uniform XML syntax, supports derivation These include the following. of document types (similar to subclassing in object-oriented Identity constraints. languages), permits ‘all’ groups and nested definitions, and • provides atomic data types (such as integers, floating point, The mapping from XML Schema syntax into compo- dates) in addition to character data. XML Schema is also • nents. more complex than DTDs, requiring a couple of hundred pages to describe, as opposed to the thirty or so in the orig- Skip and lax wildcard validation. • inal specification of XML 1.0 (which included DTDs). The The unambiguity restriction on content models. remainder of this paper assumes some familiarity with XML • Schema. The sibling element constraint. MSL (Model Schema Language) is an attempt to formalize • some of the core idea in XML Schema. The benefits of The xsi:nil attribute. • a formal description is that it is both concise and precise, A check that abstract components are not instantiated. although it does require some familiarity with mathematical • notation. Support for form and form default. MSL is described with an inference rule notation. Orig- • inally developed by logicians [7, 13], this notation is now Support for final, block, use, and value. • widely used for describing type systems and semantics of The Post Schema Validation Infoset. programming languages [10]. A basic understanding of • grammar rules and first-order predicate logic should be ad- Atomic datatypes. • We have begun to work on modeling the first two of these. We believe that most or all of the items in the above list could be modeled with additional effort. In addition, MSL differs from XML Schema on the defi- nition of restriction. We believe the definition of restriction in XML Schema is unnecessarily ad hoc, as explained in Ap- pendix A. Copyright is held by the author/owner. WWW10, May 1-5, 2001, Hong Kong. We expect an MSL document to be released by the W3C ACM 1-58113-348-0/01/0005. and for MSL to continue to evolve, as will XML Schema. This paper concentrates on the key element of MSL and XML Schema, namely normalization, refinement, and vali-
Figure 3: Normalized universal names
g1 , g2 sequence, g1 followed by g2 derivation specifies how the component is derived from the base, it is one of restriction or extension; g1 | g2 choice, g1 or g2 refinement is the set of permitted derivations from this g1 & g2 interleaving, g1 and g2 in any order (‘all’ component as base, it is a subset of restriction, group) extension ; { } g m,n repetition, g repeated between minimum m abstract is a boolean, representing whether this type is { } and maximum n times (m a natural number, abstract; n a natural number or ) ∞ content is the content of the structure, a model group. mixed(g) mixed content in group g Here are the components of the normalized schema repre- a[g] attribute, with name a and content g sented in MSL notation. component( e[g] element, with name e and content g sort = element, name = a, w wildcard base = xsi:UrElement, derivation = restriction, p atomic datatype (such as xsi:String) refinement = {restriction,extension}, x component name abstract = false, content = a[u] Here is an example of a group in MSL notation, which ) corresponds to an a element with content of type u in our component( running example. sort = simpleType, name = s, a[ base = xsi:UrSimpleType, (t/@b[xsi:String] & derivation = restriction, t/@c[xsi:Integer{0, }]{0,1}), refinement = {restriction}, (u/d[u/d/*/a[xsi:String]{1,∞ }] | abstract = false, u/d/*/e[xsi:String]) ∞ content = xsi:Integer{0, } ] ) ∞ Note that the group constructors are used uniformly in sev- component( eral contexts. Repetition (g m,n ) is used for lists of atomic { } sort = complexType, datatypes, to indicate whether an attribute is optional, and name = t, for elements. Similarly, interleaving (g1 & g2) is used for at- base = xsi:UrType, tributes and for elements. derivation = restriction, refinement = {restriction,extension}, 2.3 Components abstract = false, Next, we show how components are represented in MSL content = t/@b & t/@c ) notation. Each component is one of seven sorts: element, attribute, simple type, complex type, attribute group, or component( model group. Regardless of sort, each component is repre- sort = attribute, sented uniformly as a record with seven fields: name = t/@b, base = xsi:UrAttribute, sort is the sort of the component; derivation = restriction, refinement = {restriction}, name is the name of the component; abstract = false, content = t/@b[xsi:String] base is the name of the base component of the structure; ) component( 2.4 Documents sort = attribute, MSL also provides a compact notation for XML docu- name = t/@c, base = xsi:UrAttribute, ments, both before and after normalization. Here is the derivation = restriction, original document in MSL notation. derivation = {restricition}, abstract = false, a[ content = t/@c[s]{0,1} @xsi:type["u"], ) @b["zero"], @c[1,2], d[ component( a["three"], sort = complexType, a["four"] name = u, ] base = t, ] derivation = extension, refinement = {restriction,extension}, abstract = false, Note that attributes and elements are represented uniformly, content = (t/@b & t/@c), (u/d | u/e) as are sequences of attributes, sequences of elements, and ) lists of atomic datatypes. Here is the normalized document in MSL notation. component( sort = element, a[ name = u/d, @xsi:type["u"], base = xsi:UrElement, t/@b["zero"], derivation = restriction, t/@c[1,2], refinement = {}, u/d[ abstract = false, u/d/*/a["three"], content = u/d[u/d/*] u/d/*/a["four"] ) ] ]
component( Finally, here is the normalized document in MSL notation sort = complexType, with type information added. name = u/d/*, base = xsi:UrType, derivation = restriction, a[ u refinement = {}, 3 abstract = false, t/@b[xsi:String "zero"], t/@c[s 1,2], 3 content = u/d/*{0, } 3 ) ∞ u/d[ u/d/* u/d/*/a[xsi:String3 "three"], component( u/d/*/a[xsi:String 3 "four"] sort = element, ] 3 name = u/d/*/a, ] base = xsi:UrElement, derivation = restriction, Unlike the xsi:type convention, the MSL notation allows refinement = {}, one to uniformly express information about element and at- abstract = false, content = u/d/*/a[xsi:String] tribute types. The type of an element or attribute is indi- ) cated by writing x[t d] where x is an attribute or element name, t is a type name,3 and d is the content of the attribute or element. component( sort = element, name = u/e, base = xsi:UrElement, 3. STRUCTURES derivation = restriction, This section defines the structures used in MSL: names, refinement = {}, abstract = false, wildcards, atomic datatypes, model groups, components, content = u/e[xsi:String] and documents. ) 3.1 Names Observe that if we start with the content of the top-level a A namespace is a URI, and a local name is an NCName, node, replace the name t with its refinement u, and then as in the Namespace recommendation. We let i range over expand out all names (that is, replace the names t/@b and namespaces and j range over local names. t/@c with the contents of those attributes, and so on), then the result is the same as the model group given in the pre- vious subsection. namespace i ::= URI Note that MSL does not nest declarations to express their local name j ::= NCName scope. Instead, the scope of a declaration is reflected in its normalized name. A symbol space is one of the six symbol spaces in XML Schema. We let ss range over symbol spaces. of wildcards. We let v range over wildcard items, and w range over wildcards. symbol space ss ::= element attribute wildcard item v ::= | type | any namespace *:* attributeGroup given namespace i:* | modelGroup | | notation wildcard w ::= | wildcard item v (We make no further use of attributeGroup, modelGroup, union w1+w2 | and notation in this document.) difference w1!w2 A symbol name consists of a symbol space paired with a | local name or with * (the latter names an anonymous com- A wildcard union w1+w2 stands for any name in w1 or w2.A ponent). A name consists of a URI followed by a sequence wildcard difference w1!w2 stands for any name in w1 but not of one or more symbol names. We let sn range over symbol in w2. For example, the wildcard *:*!(baz:*+xsi:String) names, and x range over names. denotes any name in any namespace, except for names in namespace baz, and local name String in namespace xsi. symbol name sn ::= named ss::j 3.3 Atomic datatypes anonymous ss::* | MSL takes as given the atomic datatypes from XML name x ::= i#sn1/ /snl Schema Part 2 [3]. We let p range over atomic datatypes, ··· and c range over constants of such datatypes. It is sometimes convenient to use a short form of names. Typically, an atomic datatype is either a primitive For these, we make the simplifying assumption that there datatype, or is derived from another atomic datatype by are only two symbol spaces. Symbol names in the attribute specifying a set of facets. Lists of atomic datatypes are symbol space are written @j, all other symbol names are specified using repetition, while unions are specified using written j (or * for anonymous names). The URI may be alternation, as defined below. dropped when it is obvious from context. An example of an atomic datatype is xsi:String, and a Example names are shown in Figure 3. The scope length constant of that datatype is "zero". of the second to last name, with short form u/d/*/a, is 4. Before normalization, all names in a document have scope 3.4 Model groups length equal to one. It is helpful to define functions to extract the namespace from a name, and to extract the We use traditional regular expression notation for model symbol space and local name of the last symbol name. groups. Let g range over model groups. If x = i#sn1/ /snl and snl = ss::j then we define namespace(x) =···i, symbol(x) = ss, and local(x) = j. group g ::= We also introduce several subclasses of names. An at- empty sequence empty choice tribute name is the name of an attribute component, and | ∅ sequence g1 , g2 similarly for element, simple type, and complex type names. | choice g1 | g2 We let a, e, s, k range over attribute, element, simple type, | and complex type names. interleave g1 & g2 repetition | g m,n attribute name a ::= x attribute | a{[g] } element name e ::= x element | e[g] simple type name s ::= x mixed content | mixed(g) complex type name k ::= x wildcard | w atomic datatype | p A type name is a simple or complex type name. We let t component name | x | range over type names. minimum m ::= natural type name t ::= s maximum n ::= m k unbounded | | ∞ The class of a name must be consistent with its symbol An example of a group appears in Section 2.2. space. The empty sequence matches only the empty document; it is an identity for sequence and interleaving. The empty symbol(a) = attribute choice matches no document; it is an identity for choice. symbol(e) = element symbol(t) = type , g = g = g , | g = g = g | 3.2 Wildcards ∅ & g = g = g & A wildcard denotes a set of element names. A wildcard item is of the form *:* denoting any name in any names- For use with repetitions, we extend arithmetic to include pace, or i:* denoting any name in namespace i.A wildcard in the obvious way. For any n we have n + = + n = consists of wildcard items, union of wildcards, or difference ∞ and n is always true, and < n is always∞ ∞ false. ∞ ≤ ∞ ∞ 3.5 Components 3.6 Constraints A sort is one of the six sorts of component in XML Recall that the group constructs are used uniformly in Schema. We let srt range over sorts. several contexts. Repetition (g m,n ) is used for lists of atomic datatypes, to indicate whether{ } an attribute is op- sort srt ::= attribute tional, and for elements. Similarly, interleaving (g1 & g2) is element | used for attributes and for elements. The advantage of this simpleType approach is that the semantics of groups is uniform, and | complexType | need be given only once. Thus, for instance, how repeti- attributeGroup tion acts is defined once, not separately for attributes and | modelGroup | elements. (We make no further use of attributeGroup or modelGroup However, it is helpful to define additional syntactic cate- in this document.) gories that specify various subsets of groups. These syntactic A derivation specifies how a component is derived from classes are then used to constrain the content of components, its base. We let der range over derivations, and ders range for instance, to indicate that the content of an element com- over sets of derivations. We let b range over booleans. ponent should be an element, and that the content of a type component should consist of attributes followed by elements. derivation der ::= extension An attribute group contains only attribute names, com- refinement bined using interleaving. An element group contains no at- | tribute names. derivation set ders ::= der1, , derl { ··· } boolean b ::= true attribute group ag ::= false empty sequence | interleaving ag1 & ag2 A component is a record with seven fields. attribute name | a | sort is the sort of the component (srt); element group eg ::= empty sequence name is the name of the component (x); empty choice | ∅ sequence eg1 , eg2 base is the name of the base component of the structure | choice eg1 | eg2 (x); | interleaving eg1 & eg2 derivation specifies how the component is derived from the repetition | eg m,n base (der); wildcard | w { } element name | e is the set of permitted derivations from this refinement type name | t component as base (ders); | abstract is a boolean, representing whether this type is (Interleaving in element groups might be further con- abstract (b); strained, as in Schema Part 1, Section 5.7, All Group Lim- ited.) content is the content of the structure, a model group (g). Given the above, we can specify the allowed contents of the four sort of component as follows. An attribute content We let cmp range over components. is either an attribute or an optional attribute, where the component cmp ::= component( content is a simple type name. An element content is an sort = srt element where the content is a type name. A simple type name = x content is an atomic datatype or a list of atomic datatype. base = x A complex type content is an attribute group followed by derivation = der either a simple type content or an element group. refinement = ders abstract = b attribute content ac ::= content = g attribute a[s] ) optional attribute a[s] 0,1 | { } Examples of components appear in Section 2.3. element content ec ::= For a given schema, we assume a fixed dereferencing map element e[t] that takes names to the corresponding components. We union content uc ::= write deref(x) = cmp if name x corresponds to component atomic datatype p cmp. union uc | uc The dereferencing map must map attribute names to | simple content sc ::= attribute components, and similarly for elements, simple union uc types, and complex types. list uc m,n | { } deref(a).sort = attribute complex content kc ::= deref(e).sort = element simple ag , sc deref(s).sort = simpleType element ag , eg deref(k).sort = complexType mixed | ag , mixed(eg) | b["two"], g1 = a[xsi:Integer], and g2 = b[xsi:String]. The content of each sort of component corresponds to the Then since both syntax above. That is, the content of an attribute com- a[1] a[xsi:Integer] ponent is always an attribute content ac; the content of an ∈ element component is always an element content ec; the con- and tent of a simple type component is always a simple content b["two"] b[xsi:String] sc; and the content of a complex type component is always ∈ a complex content kc. Further, for an attribute or element hold, we may conclude that component the name of the component is the same as the a[1] , b["two"] a[xsi:Integer] , b[xsi:String] name of the attribute or element in its content. ∈ It is easy to confirm that the example components in Sec- holds. tion 2.3 satisfy these constraints. 3.7 Documents 4. NORMALIZATION Normalization of a document replaces each name by the A document is a sequence of items, where each item is corresponding normalized name, and adds type information an atomic datatype, or an attribute (with a document as to the document. Normalization is performed with respect content), or an element (with a document as content). We to a given schema; in our formalism the schema is deter- let d range over documents. mined by the dereferencing map, deref(). Section 2.4 gives document d ::= an example of a document before and after normalization. empty document Prior to normalization, all names in the document have exactly one symbol name. To build normalized names, we sequence d1 , d2 constant | c use an operation that extends a name with an additional attribute | a[d] symbol name. Let x1 and x2 be two names, and where the element | e[d] second name has only one symbol name. We write x1£x2 for | the operation that extends x1 by adding the symbol name Examples of documents appear in Section 2.4. of x2 (if they are in the same namespace) or is the name x2 A typed document is a document with added type infor- (if they are in different namespaces). mation for each element and attribute. We let td range over i#sn1/ /snl £ i#sn = i#sn1/ /snl/sn typed documents. ··· ··· i#sn1/ /snl £ i0#sn = i0#sn, i = i0 ··· 6 document td ::= For each sort there is a root type (AnyType, AnyElement, empty document etc), for which we define sequence td1 , td2 constant | c x £ AnyElement = AnyElement. attribute | a[s d] In effect, the root types are in a fixed namespace, so the rule element | e[t 3td] | 3 for roots is subsumed by the rule for different namespaces. Examples of typed documents appear in Section 2.4. Typed We write x a a0 or x e e0 to indicate that in documents are the result of normalization, Section 4. the context specified` ⇒ by name `x that⇒ attribute name a nor- An document item is either a constant of atomic datatype, malizes to a0 or that element name e normalizes to e0. To or an attribute, or an element. normalize an attribute or element name we extend the con- text by the name (if extension yields the normalized name of document item di ::= some component; these are the ‘extend’ rules), or use the el- constant c ement name directly (otherwise; these are the ‘reset’ rules). | attribute a[c] We write x dom(deref()) and x deref() to indicate | element e[d] whether or not∈ x is in the domain of the6∈ dereferencing map; | Document items are used to define interleaving, Section 6. that is, whether or not x names some component. x £ a dom(deref()) 3.8 Inference rules ∈ x a x £ a Operations such as normalization and validation are de- ` ⇒ scribed with an inference rule notation. Originally devel- (extend attribute) oped by logicians [7, 13], this notation is now widely used x £ e dom(deref()) for describing type systems and semantics of programming ∈ languages [10]. In this notation, when all judgements above x e x £ e the line hold, then the judgement below the line holds as ` ⇒ (extend element) well. Here is an example of a rule used later on. We write d g if document d validates against group g. x £ a dom(deref()) ∈ 6∈ x a a ` ⇒ d1 g1 d2 g2 (reset attribute) ∈ ∈ (sequence) d1 , d2 g1 , g2 ∈ x £ e dom(deref()) 6∈ The rule says that if both d1 g1 and d2 g2 hold, then d1 , x e e ∈ ∈ ` ⇒ d2 g1 ,g2 holds as well. For instance, take d1 = a[1], d2 = (reset element) ∈ We write x d dt to indicate that in the context 5.3 Restriction specified by name` x⇒that document d normalizes to typed We write g <:res g0 if the instances of group g are a subset document td. We write @xsi:type d if d does not con- 6∈ of the instance of group g0. That is, g <:res g0 if for every tain an xsi:type attribute. Note that the type names in document d such that d g it is also the case that d g0. xsi:type attributes always refer to global types and need ∈ ∈ not be normalized. 5.4 Constraints A schema must satisfy certain constraints on refinement (constant) x c c0 to be well-formed. Define x <:der x0 to be x <:res x0 if der = ` ⇒ restriction and x<:extx0 if der = extension. We write x ` (empty document) to indicate that the component with name x is well-formed x ` ⇒ with respect to refinement.
x d1 td1 y d2 td2 ` ⇒ ` ⇒ (sequence) x0 = deref(x).base x d1 , d2 td1 , td2 ` ⇒ der = deref(x).derivation der deref(x0).refinement x a a0 ∈ ` ⇒ deref(x).content <:der deref(x0).content deref(a0).content = a0[s] or x deref(a0).content = a0[s] 0,1 ` s d td { } (refinement) ` ⇒ x a[d] a0[s td] ` ⇒ 3 (attribute) 6. VALIDATION
We write c p p if constant c validates against atomic x e e0 datatype p. We∈ do not specify this relation further, but @xsi:type` ⇒ d 6∈ simply assume it is as defined in Schema Part 2. deref(e0).content = e0[t] We write e v v and e w w if element name e validates t d td ∈ ∈ against wildcard item v or wildcard w. We write e w w if ` ⇒ 6∈ x e[d] e[t td] it is not the case that e w w. ` ⇒ 3 (untyped element) ∈ (any namespace) x e e0 e v *:* ` ⇒ ∈ deref(e0).content = e0[t0] t <: t0 namespace(x) = i t d td ` ⇒ e v i:* x e[@xsi:type[t], d] e[t td] ∈ (given namespace) ` ⇒ (typed3 element)
The (typed element) rule uses the relation x<:x , which e v v 0 ∈ (wildcard item) is defined Section 5.1. e w v ∈
5. REFINEMENT e w w1 ∈ (wildcard sum 1) e w w1+w2 5.1 Base chain ∈ We write x<:x0 if starting from the component with name e w w2 x one can reach the component with name x0 by successively ∈ (wildcard sum 2) following base links. e w w1+w2 ∈ (reflexive) x <: x e w w1 e w w2 ∈ 6∈ e w w1!w2 x <: x0 x0 <: x00 ∈ (wildcard difference) (transitive) x <: x00
We write d inter d0 ; d00 (read “d interleaves d0 and d00”) deref(x).base = x0 7→ (base) if some interleaving of d0 and d00 yields d. This relates one x <: x0 sequence to many pairs of sequences. For example,
a[1],a[2],a[3] inter a[1],a[2] ; a[3] 5.2 Extension 7→ a[1],a[2],a[3] inter a[2] ; a[1],a[3] We write g <:ext g0 if group g is derived from group g0 7→ a[1],a[2],a[3] inter ; a[1],a[2],a[3] by adding attributes and elements. It is specified using at- 7→ tribute groups ag and element groups eg as defined in Sec- among other possibilities. This is used in the rule for inter- tion 3.6. leaving, g1 & g2.
(extend) (interleave empty) ag , eg <:ext (ag & ag0) , eg , eg0 inter ; 7→ d1 inter d0 ; d00 d2 inter d0 ; d00 d g 7→ 1 1 7→ 2 2 ∈ (element) d1 , d2 inter d10 , d20 ; d100 , d200 e[d] e[g] 7→ (interleave sequence) ∈ d unmix d0 d0 g 7→ ∈ (mixed group) (interleave item 1) d mixed(g) di inter id ; 7→ ∈ d s (interleave item 2) ∈ (typed attribute) di inter ; di e[s d] e[s] 7→ 3 ∈
We write d unmix d0 (read “d unmixes to d0”) if d is a d t t <: t0 7→ ∈ (typed element) sequence of elements and character data and d0 is the same e[t d] e[t0] sequence with all character data removed. For example, 3 ∈
a[1],"x",a[2] unmix a[1],a[2] d e e w w 7→ ∈ ∈ (wildcard) d w This is used in the rule for mixed content, mixed(g). ∈
c p p (unmix empty) ∈ (atomic datatype) unmix c p 7→ ∈
d1 unmix d10 d2 unmix d20 d e e <: e0 7→ 7→ ∈ d1 , d2 unmix d10 , d20 d e 7→ 0 (unmix sequence) ∈ (element refinement)
(unmix element) d g g = deref(x).content e[d] unmix e[d] ∈ 7→ d x ∈ (component name)
c unmix 7→ (unmix character data) The (typed element) and (element refinement) rules use the relation x <: x0, which is defined Section 5.1. The We write d g if document d validates against model check that t<:t0 in the (typed element) rule is redundant, group g. ∈ as it is also performed during normalization. When processing a normalized document with types, the (empty) (attribute) and (element) rules are not required, the (typed attribute) and (typed element) are used in- ∈ stead.
d1 g1 d2 g2 ∈ ∈ (sequence) d1 , d2 g1 , g2 7. REFERENCES ∈ [1] Serge Abiteboul, Peter Buneman, and Dan Suciu. Data on the Web : From Relations to Semistructured d g1 ∈ (choice 1) Data and XML. Morgan Kaufmann, 1999. d g1 | g2 ∈ [2] Alfred V. Aho. Algorithms for finding patterns in strings. In Jan van Leeuwen, editor, Handbook of d g2 ∈ (choice 2) Theoretical Computer Science. MIT Press Elsevier, d g1 | g2 Cambridge, Massachusetts, 1990. ∈ [3] Paul V. Biron and Ashok Malhotra, editors. XML d inter d1 ; d2 d1 g1 d2 g2 Schema Part 2: Datatypes. World Wide Web 7→ ∈ ∈ Consortium, 2000. d g1 & g2 ∈ (interleave) [4] Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen, editors. Extensible Markup Language (XML) 1.0. World Wide Web Consortium, 1998. d1 g d2 g m,n ∈ ∈ { } (repetition 1) [5] James Clark and Steve DeRose, editors. XML path d1 , d2 g m + 1,n + 1 ∈ { } language (XPath) version 1.0. World Wide Web Consortium, 1999. d1 g d2 g 0,n ∈ ∈ { } (repetition 2) [6] David C. Fallside, editor. XML Schema Part 0: d1 , d2 g 0,n + 1 Primer. World Wide Web Consortium, 2000. ∈ { } [7] Gottlob Frege. Begriffsschrift, a formula language, (repetition 3) modeled upon that of arithmetic, for pure thought g 0,n ∈ { } (1879). In Jan van Heijenoort, editor, From Frege to G¨odel:A Source Book in Mathematical Logic, d g 1879-1931. Harvard University Press, Cambridge, ∈ (attribute) a[d] a[g] Massachusetts, 1967. ∈ [8] Haruo Hosoya, Jerome Vouillon, and Benjamin C. to match w (and this is what happens in MSL), but Pierce. Regular expression types for xml. In Schema Part 1 does not appear to consider this case. Proceedings of the International Conference on Functional Programming (ICFP), 2000. B. SUGGESTIONS FOR XML SCHEMA [9] Tova Milo and Dan Suciu. Type inference for queries on semistructured data. In Proceedings of the ACM Restriction. Change the definition of restriction to the Symposium on Principles of Database Systems, 1999. • one used in this document. One type is a restriction [10] John C. Mitchell. Foundations for Programming of another if every instance of the first type is also an Languages. MIT Press, Cambridge, Massachusetts, instance of the second. 1996. Uniformity. Change the name equivClass to base, to [11] Henry S. Thompson, David Beech, Murray Maloney, • emphasize the uniformity between elements and types. and Noah Mendelsohn, editors. XML Schema Part 1: Wildcards. Specify how wildcards interact with equiv- Structures. World Wide Web Consortium, 2000. • alence classes. (See discussion in Appendix A.) [12] Philip Wadler. A formal semantics of patterns in Symbol spaces. Combine all symbol spaces other than XSLT. In B. Tommie Usdin, Deborah A. Lapeyre, and • C. M. Sperberg-McQueen, editors, Proceedings of attribute. This allows one to use the short form of Markup Technologies, Philadelphia, 1999. naming described in the document. For instance, in [13] Philip Wadler. New language, old logic. Dr Dobbs place of Journal, December 2000. type::u/element::d/type::*/element::a one could write u/d/*/a, and in place of APPENDIX type::t/attribute::b A. PROBLEMS WITH XML SCHEMA one could write t/@b. Restriction. The following problems were uncovered in • Schema Part 1, Section 5.10, which describes restric- tion. – Complexity. An attempt at defining formal rules corresponding to the definition of restriction re- quired more than 100 lines of formal rules (as com- pared to the one-line definition given in the current document). Many rules had five or six premises. – Transitivity. There appear to be numerous cases where type t is a restriction of type t0 and type t0 is a restriction of type t00, but type t is not a restriction of type t00, according to the given rules. – Ad hoc. As noted below, many of the choices in the defition of restriction seem arbitrary. – Elt:Elt–NameAndTypeOK. Why the constraint that nullable of R and B be identical? A weaker constraint is more sensible: if R is nullable then B must be nullable. That is, it is fine for R not to be nullable even if B is nullable. – Elt:Elt–NameAndTypeOK. Why is it ok for the cor- responding types to be related by list or extension, but not by restriction? Clearly, restriction should be allowed. – Elt:All/Choice/Sequence—RecurseAsIfGroup. Why does Elt:All/Choice/Sequence recurse, but Wildcard:All/Choice/Sequence is forbidden? Recursion seems equally sensible for both. – All:All–Recurse vs. Sequence:All–RecurseUnorder- ed. Why must the former maintain order while the latter need not? Losing order seems equally sensible for both. Wildcards. Say that element e is in the equivalence • class of element e0 (that is, that e has base e0), and that elements e and e0 are in different namespaces, and that a wildcard w includes the namespace of e0 but not of e. If the wildcard is strict, does element e validate against wildcard w? Intuitively, one would expect e