This document lists issues open (or proposed) against the draft formalization of XML Schema. In its current form it has been prepared by Michael Sperberg-McQueen.
| Num | Cl | Cluster | Status | Originator | Responsible | Description |
|---|---|---|---|---|---|---|
| F-1 | nuns | abandoned | Beech | Do MSL names deal with schemas or schema documents? | ||
| F-2 | nuns | abandoned | Beech | Clarify MIME type assumptions, resolve conflict with ID? | ||
| F-3 | nuns | abandoned | Beech | Are URIs in normalized unique names dereferenceable? | ||
| F-4 | nuns | abandoned | Beech | Eliminate ambiguity in n-u-ns? | ||
| F-5 | 1 | ext | resolved | Beech | Align terminology with RFC 2396? | |
| F-6 | nuns | abandoned | Beech | What is the URI in a n-u-n for a schema(doc) with no target namespace? | ||
| F-7 | 1 | clean | resolved | Beech | Stick with multiple symbol spaces? | |
| F-8 | nuns | abandoned | Beech | How handle absent namespace in sec 3.2? | ||
| F-9 | cm | proposed | Thompson | To what does the name of a local element refer? | ||
| F-10 | 1 | cm | resolved | WG | Associativity of all-operator needs to be repaired | |
| F-11 | clean | proposed | Sperberg-McQueen | Should the grammar be made more restrictive? | ||
| F-12 | alignment | proposed | WG | Should the rules for components be made more restrictive? | ||
| F-13 | nuns | abandoned | WG | What should be the normalized name of an unqualified local? | ||
| F-14 | norm | proposed | WG | Should instance normalization be schema-independent? | ||
| F-15 | alignment | proposed | Fuchs | Simplify rules for complex-type restriction? | ||
| F-16 | clean | proposed | Beech | Provide easy means of proving invalidity? | ||
| F-17 | cov | proposed | WG | Model monotonicity of restriction and extension? | ||
| F-18 | cm | proposed | Editors | Wildcards need strict / lax / skip info? | ||
| F-19 | cov | proposed | Sperberg-McQueen | Model xsi:type determinant for unions? | ||
| F-20 | ext | proposed | TF | Rules for extension? | ||
| F-21 | ext | proposed | Wadler | Rules for restriction? | ||
| F-22 | ext | proposed | Chamberlin | Will/should function resolution work over substitution groups? | ||
| F-23 | ext | proposed | Robie | Alignment with Query data model and algebra? | ||
| F-24 | keys | proposed | Simeon, Brown | Add/clarify account of keys and foreign keys? | ||
| F-25 | 1 | how | unassigned | Goodchild, Vedamuthu | Editorial issues? | |
| F-26 | unassigned | unassigned | Simeon | Interaction between subtyping and name normalization? | ||
| F-27 | ext | proposed | Goodchild | Implications for and from XPath 2.0? | ||
| F-28 | how-nuns | abandoned | TF | Should the naming conventions be published separately? | ||
| F-29 | alignment | proposed | Wadler | How are schema components exposed to downstream apps? | ||
| F-30 | alignment | unassigned | Sperberg-McQueen | Transfer syntax or components? | ||
| F-31 | 1 | how | closed | Sperberg-McQueen | CR not LC | |
| F-32 | cov | proposed | WG | Include simple types? | ||
| F-33 | 1 | how | closed | Jim Trezzo | Revise status description | |
| F-34 | norm | proposed | David Beech | Normalization | ||
| F-35 | 1 | clean | closed | MSM | Make the example schema legal | |
| F-36 | nuns | abandoned | MSM | What's a legal name? | ||
| F-37 | nuns | abandoned | MSM | Completeness of NUN design | ||
| F-38 | how | proposed | Noah Mendelsohn | Clarify which parts of this might go farther? | ||
| F-39 | cm | active | David Beech | Consistent usage for 'group', 'model group', 'content model' | ||
| F-40 | cm | active | David Beech | Model groups | ||
| F-41 | 1 | clean | active | Trezzo | Correct examples | |
| F-42 | nuns | abandoned | MSM | Aliasing | ||
| F-43 | alignment | proposed | MSM | Name-based type equivalence and structural equivalence | ||
| F-44 | alignment | proposed | David Beech | Align with structures | ||
| F-45 | cm | proposed | David Beech | Empty sequence and empty choice | ||
| F-46 | term | proposed | David Beech | Various terminological points | ||
| F-47 | clean | proposed | David Beech | Generalizations | ||
| F-48 | keys | proposed | Vedamuthu | Identity constraints | ||
| F-49 | cov | proposed | Holstege | Where are notations? | ||
| F-50 | uncl | proposed | David Beech | Clarify refinement=() | ||
| F-51 | cov | proposed | MSM | Mixed and element-only content | ||
| F-52 | cov | proposed | MSM | Union types and their members | ||
| F-53 | term | active | MSM | Model groups don't include attributes | ||
| F-54 | 1 | how | closed | Mendelsohn | Make clear that this is a paper notation only? | |
| F-55 | how-nuns | abandoned | Thompson | Real NUNs | ||
| F-56 | nuns | abandoned | Holstege | Star for anonymous | ||
| F-57 | clean | proposed | MSM | Tighten the grammar for symbol names | ||
| F-58 | alignment | proposed | Vedamuthu | Wildcard expression and components | ||
| F-59 | 1 | cm | closed | David Beech | Wildcards apply to attributes | |
| F-60 | uncl | active | MSM | Need example of precedence rules | ||
| F-61 | cov | proposed | Vedamuthu | Coverage (atomic types) | ||
| F-62 | cm | proposed | David Beech | Need an empty ALL-group? | ||
| F-63 | cm / alignment | proposed | David Beech | Would content models with empty sequence, choice be legal? | ||
| F-64 | 1 | term | close | MSM | The term document | |
| F-65 | ext | proposed | HST | Formalizing XPath? | ||
| F-66 | 1 | clean | closed | WG | Index of notations | |
| F-67 | 1 | how | closed | WG | Confessing to infidelities | |
| F-68 | nuns | abandoned | MSM | Nuns colliding with XPath | ||
| F-69 | term | proposed | MSM | The meaning of model groups | ||
| F-70 | ext | unassigned | Philip Wadler | Alignment with query algebra | ||
| F-71 | 1 | how | proposed | MSM | Name of the document |
Do the URIs in normalized universal names refer to schemas? to schema documents (or analogous resources)? to namespaces?
Input from David Beech:
1) Section 2.1: baz.xsd is a schema document, but "schema" often seems to be used interchangeably with "schema document" - does it always mean "schema document" or do MSL names deal with a more abstract model of a schema? What happens to <include>?
...
4) If a URI is used that does not resolve to a schema document, is the name then only universal in the sense that it is not necessarily uniquely defined, but may have as many versions as there are schema documents for its namespace?
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
Assumptions and possible interactions with MIME types and other fragment-identifier syntaxes must be clarified. It may be useful to provide an xschema wrapper analogous to the existing xpointer wrapper to avoid conflicts when a schema is served as text/xml.
Input from David Beech:
2) 2.1: What assumption is made about the MIME type at the # that
begins the fragment identifier? Is the fragment identifier syntax
such as element::a unambiguous when added to a URL in the
http scheme, or could it conflict with an id? XPath in a fragment
identifier has to be wrapped in the xpointer(...) scheme
- should schema name "paths" be wrapped in xschema(...)
in the long form?
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
When the URI in a normalized unique name is an http URL, is it (should / may / must it be) dereferenceable?
Input from David Beech:
3) Are the http URLs dereferenceable? Is there a description somewhere of how an instance may be associated with a potential schemaLocation for a namespace?
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
The short forms given for normalized universal names are ambiguous in some cases. Should this ambiguity be eliminated? If so, how?
Input from David Beech:
5) The short form differs in principle from that in XPath, because it is not in general unambiguously translatable back to the long form. Would it be a better idea to use the same convention as XPath, and require explicit axes except for the element and attribute cases?
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
The MSL document uses the term URI where it should (following RFC 2396 and the Namespaces in XML Recommendation) use URI-reference; this should be repaired.
Input from David Beech:
6) Section 3.1: I believe a namespace corresponds to a URI-reference, not just a URI, i.e. it may already have an optional fragment identifier before one begins any xschema navigation. It was not a great choice of terminology in RFC2396, but they give a formal definition of it and it would be confusing to conflict with that.
At its face to face meeting of 1-2 March 2001 in Cambridge, Mass., the WG voted to close this issue, on the grounds that the text had been corrected.
The symbol i is described as ranging over URIs (or URI references); it appears to need a broader range in order to handle schema documents with no target namespace.
Input from David Beech:
7) i seems to need to range formally over something besides URIRefs in order to cater for the absence of any namespace qualifier - as of course the Namespaces REC has to allow. What then would be the long name of a component in a schema document with an absent targetNamespace?
The production has been changed to make i range over URI references and the empty string.
At its face to face meeting of 1-2 March 2001 in Cambridge, Mass., the WG voted to mark this issue non-urgent, but not to close it, on the grounds that the empty string has a meaning as a URI reference, so that the solution proposed introduces an ambiguity.
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
The draft "make[s] the simplifying assumption that there are only two symbol spaces"; this assumption does not seem to simplify things, and in any case it's not true. Should it be fixed?
Input from David Beech:
8) "We make the simplifying assumption that there are only two symbol spaces." It's not necessarily simpler for the end user. Since there's a simple solution for MSL as in 5) above, to do what XPath does, I hope we can avoid reopening the issue, the pros and cons of which were debated at some length by the WG.
At its face to face meeting of 1-2 March 2001 in Cambridge, Mass., the WG discussed this issue. The document now just says we have used the short form as a convenience, but there is no collapsing of symbol spaces and we have arranged examples so there is no ambiguity. This will come up again should short form get wider use, but for now the WG agreed without objection to close this issue.
How should the absence of a namespace be handled in section 3.2 of the draft?
Input from David Beech:
9) Section 3.2: How should the absence of a namespace be handled here?
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
If a complex type has a sequence with element a (string), element b (number), and element a (string), does the name element::a refer to the first declaration, to the second, to both, or to some abstraction of the two? In other words, do the normalized universal names operate at at component level or syntax level?
Do the normalized universal names refer in this case to particles in the content model, to element declarations, or to components in the schema?
The draft describes the all operator as associative. It's not. Fix it?
At its face to face meeting of 1-2 March 2001 in Cambridge, Mass., the WG discussed this issue. The editorial changes described appeared to the WG to have solved the problem reported here. The WG agreed without objection to close this issue.
The syntax rules in the draft generate expressions which cannot be translated into our transfer syntax, and which do not correspond to any legal schema at the component level. Is this acceptable (what is really essential is that the rules cover all legal cases, not that they cover no others), or should the rules be tightened up to make them less confusing?
The component rules in the draft allow MSL-components which have no equivalents in legal schemas. Is this OK, or should there be well-formedness constraints to ensure that operations at the MSL level do not generate components which are not legal under XML Schema?
If local elements are unqualified (instead of being qualified with the same namespace name of the type to which they are local), e.g. as in
<a:f>
<b>
|
then what should the normalized name of the b element be?
The draft says or implies that the
normalized name of the f element is {a}#e::f,
and that of the b element is {a}#e::f/e::b.
But the rule says that only works if they are in the same namespace, but in
unqualified case that isn't so.
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
Should you be able to normalize names in instance without reference to the schema? (Currently, it is necessary to know the set of normalized names defined by/for/in a schema.)
The formal treatment of the rules governing restriction of complex types is complicated; it would be simpler if the rules just said the language generated by the restricted type must be a sublangage of that generated by the base type. Should we abandon the details?
The draft defines sets of conditions sufficient for proving the something is valid; the invalidity of a schema or document effectively consists in our inability to prove it valid. Might it be useful to provide rules from which one can directly prove that something is invalid (without having to resort to meta-logical proofs about the impossibility of proving it valid within a given system)?
The draft does not implement the monotonicity of restriction / extension. It should.
Wildcards must be specified as strict, lax, or skip.
The treatment of type derivation probably needs to be modified to agree more closely with that of the spec; otherwise it will not be possible to model the use of xsi:type as a determinant to force the value to be parsed as a value of some type other than the default interpretation.
In the XML Query algebra, extension is defined as disallowing the use, in the suffix, of any element type already present in the model of the base type. This restriction is not shared by XML Schema or by MSL; some in the Query WG wish it were.
The XML Query algebra's definition of restriction is different from Schema; Schema disallows many options, and the differences are difficult to reconcile.
Will function resolution work over substitution groups?
Are the Query data model and algebra fully aligned with MSL?
The draft needs a complete and clear account of keys and foreign keys. The method of formalizing reference types needs discussion.
The draft needs a fuller elaboration of the design decisions behind MSL.
It needs a clear discussion of coverage: what is and what is not covered here?
It should make clear how the Query Language and other users of schema can benefit from the formalization.
It should explain its notation more thoroughly.
The WG discussed this at its 1-2 March 2001 meeting in Cambridge. Some WG members asked whether the formalization in this document will eventually be turned into IDL or UML or something; are there machine readable versions of this to make it usable? Robie responded that it is being used at formalism level for defining query algebra, not implementation level. He has written an XML vocabulary and done some work with it, but we don't need to expose machine-processable version -- it just adds more work -- we just need to make sure to have formalism so Query and XPath 2.0 can go forward. Other members of the WG continued to argue that a machine-readable form would be a useful adjunct.
The editor was instructed to make some changes, but this issue was not closed.
What is the interaction between subtyping and name normalization?
What implications does MSL have for XPath 2.0? And vice versa?
The work on naming conventions seems to have wide potential application; can/should it be published separately?
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
How are schema components exposed to queries, APIs?
Should we should consider using the XML form of the PSV Infoset to get at schema information?
Should the formalization be based on the XML Schema transfer syntax (as in the draft) or on the components defined in the spec?
The WG discussed this issue at some length in its meeting of 1-2 March 2001 in Cambridge, Mass. The editor was instructed to add language to the draft saying that in future versions of this document, a mapping from the abstract components of XML schema to the components defined here will be defined, because it is the component level and not the transfer syntax level that is fundamental to XML Schema.
The document should be based on the CR draft (modified to agree with any changes we make), not on the draft of 7 April. And it should say so.
The WG voted at its teleconference of 15 March 2001 to close this, on the grounds that the draft had been revised to take care of the problem.
Coverage - include simple types or not? More generally, what aspects of XML Schema need to be covered?
The status section should be updated, to reflect the fact that the document has been mainstreamed. The primary goal should be described as documenting a formal model of our CR spec.
Editorial Issue: kill the phrase 'hindered by the current description' and say 'by lack of formal model'.
The WG voted at its teleconference of 15 March 2001 to close this, on the grounds that the draft had been revised to take care of the problem.
Issue (Beech): these paragraphs introduced the term 'normalization' -- concerned about the use of that term. It has other meanings, which will lead to confusion. A different term should perhaps be found.
Issue (MSM): the schema is not legal. All examples should be valid unless their goal is to illustrate an error.
The WG voted at its teleconference of 15 March 2001 to close this, on the grounds that the draft had been revised to take care of the problem.
Issue (MSM): There is no formal specification of what constitutes a legal name in this naming scheme. (See proposed grammar below.)
MF observes that this is not quite true: there is a formal grammar on page 9. Perhaps it needs to be revised.
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
Issue (MSM): The naming scheme provided does not provide names for all the nameable components of schemas.
In discussion we established that the grammar provided later in the document does actually show how to produce names for all nameable components, but the examples in section 2.1 don't illustrate names for all component types.
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
Issue (Mendelsohn): MSL can be viewed from two perspectives:
We need to sort this out very clearly for readers, and get into the habit right now, from the beginning, of making clear which side of the fence each thing belongs to.
NM observed that perhaps the question of moving naming, and possibly other material, into a separate document was a reflection of the same underlying issue regarding the breadth of application we expect things in MSL to have: internal only, or external also? MSM said he believed that was precisely the point at issue in the question of separating things out into other documents. The point raised by Allen Brown is also relevant here: some comments on the naming (including most of MSM's) reflect an unstated requirement that the naming conventions should not only suffice for the needs of MSL but should also be useful for other things (such as making first-class Web-nameable objects for each construct in a schema).
Editorial Issue (Beech): the last sentence needs to have informal forward reference to the following subsections. Matthew Fuchs thought the solution might possibly to change para 1 sentence 2. In general, we need usage for the terms 'group', 'model group', and 'content model' which is (a) consistent within MSL and (b) consistent with the usage in the Structures spec. These terms should be defined before use, or there should be a forward reference to the definition.
Issue (Beech): to what construct in structures does 'model group' correspond?
Issue (Trezzo): examples all need to be correct. Here, the spelling of integer and string is wrong.
Input from Ray S. Waldin:
The WG voted at its teleconference of 15 March 2001 to close this, on the grounds that the draft had been revised to take care of the problem.
The issue was reopened 20 March 2001 in consequence of a reader's observation that the examples still have well-formedness, editorial, and schema-validity problems.
Issue (MSM): Is aliasing possible? Should it be? I.e. should it be possible to construct two names for the same construct? Editorially, the document needs to say up front whether it is possible or not. (It becomes apparent that the intention is for aliasing not to be possible, but this should be said earlier and more explicitly.) Substantively, the WG needs to decide whether aliasing should be possible.
Matthew Fuchs observed that the document is currently designed with the assumption of a 1:1 mapping between NUNs (normalized univeral names) and constructs. Names are thus currently both unambiguous (except for the noted ambiguity of some short forms) and unique. MSM noted that allowing aliasing would simplify use of the NUNs outside of MSL (as described in his commentary), and defining one name as the canonical name would preserve the 1:1 mapping where needed. He observed that here, again, we must ask whether usability outside of MSL is a requirement or not.
David Beech asked whether the naming convention would be the same if one were using the structures component model rather than the MSL component model? Or are the names defined here inseparable from the MSL model? Matthew Fuchs said he thought they would be the same; MSM concurred.
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
Editorial Issue (MSM): the document needs to make explicit whether it uses name-based or structure-based equivalence/equality. (Substantively, it had better be using name-based equivalence/equality/identity, because that is what Part 1 uses.)
Issue (Beech): in general, MSL should be aligned with the existing structures component model.
Issue (Beech): do empty sequence and empty choice correspond to anything in structures?
ISSUE (Beech): In general, the uniformity of component model imposed here makes generalizations that don't pay off (details as just given).
ISSUE (Vedamuthu): not sure whether we can capture identity constraint definitions using the model presented here. They may not fit.
ISSUE (Holstege): where are notations?
ISSUE (Beech): Need to clarify the use / meaning of the
refinement = {}
|
seen in the examples.
AV noted that when identity constraint definition is solved, we will need an example here. And since these examples are based on the sample schema, we may want/need to extend the sample schema.
ISSUE (MSM): how are mixed and element/only content distinguished?
ISSUE (MSM): how do we use these components to record the relation betweeen a union type and its members?
ISSUE (MSM): the term 'model group' should not be used to denote something that includes attributes; it's confusing.
ISSUE (Mendelsohn): We need to be clear that in this case we are creating this notation solely to simplify the expression of the inference rules, and ensure that readers understand that we have no intention that software should read or write this notation or anything related 1:1 to it. MSM said "You mean, we should make clear this is a paper notation only?" More or less, yes. The notation here (so NM) is specifically intended only for the mechanisms within this document itself. It is not to be confused with another form or definition of the infoset or with document annotation. Allen Brown asked whether all NM wanted was a specific statement to this effect, and whether such a statement would fully resolve this issue? Yes.
The WG voted at its teleconference of 15 March 2001 to close this, on the grounds that the draft had been revised to take care of the problem.
Section 3.1 Names
ISSUE (Thompson) (already in list?): Either we should explicitly forestall any understanding or second guessing that this is a proposal for real universal names, or else we should step up to the question of producing real universal names, and look at questions like escaping URIs etc.
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
ISSUE (Holstege): the use of '*' for anonymous is endlessly confusing.
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
ISSUE (MSM): the grammar for symbol names needs to be tighter.
Section 3.2 Wildcards
Asir Vedamuthu noted that the second wildcard expression is more powerful than the component model. (Cf. issue CR-20. Cf. also AV's posting which is not yet in the issues list.)
ISSUE (Beech): wildcards apply to attribute names as well, so first sentence is erroneous.
In its teleconference of 2001-03-15, the WG voted to instruct the editor to insert wording to make clear that wildcards apply to attributes and to close this issue.
EDITORIAL ISSUE (MSM): The text needs an illustration to clarify the precedence rules, after the last sentence. Nothing fancy, just a sentence like "So the expressions ... and ... are synonymous", where one expression has parentheses and one does not.
Section 3.3 Atomic datatypes.
ISSUE (Vedamuthu): The first sentence talks about coverage. (By taking the simple types as given, the document is saying they won't be formalized.) The WG must agree or disagree.
Allen Brown noted for the record that there is disagreement among the editors about the inclusion/noninclusion of atomic types. He for one thinks they should be formalized, too.
David Beech asked whether the term 'atomic' is used in part 2? Yes, it is.
ISSUE (Beech): if we have explicit empty sequence and empty choice, we surely need an explicit empty ALL-group?
Henry Thompson noted that empty sequences and empty choices are importantly different. MSM observed that concatenation with the empty sequence is the identity function, and disjunction with the empty choice is the identity function, and wondered what an explicit empty ALL might mean (i.e. for what operation would it fulfil an analogous role)? Allen Brown replied that the semantics of ALL is a choice among all possible sequences, so the empty ALL-group would be a disjunction over empty sequences. [And in fact on closer examination MSM notes after the fact that the text says explicitly "The empty sequence matches only the empty document; it is an identity for sequence and all."]
Asir Vedamuthu noted that the distinction between mixed and element-only content appears to be addressed here.
ISSUE (Beech): the fact that empty sequence and empty choice are legal groups seems to mean that one could construct a content model with them. Is that contemplated?
Section 3.7 Documents
ISSUE (MSM): the term 'document' is used here for items without a single root; in an XML context, this seems gratuitously confusing. Some term like 'content' or 'hedge' would be better.
In its teleconference of 2001-03-15, the WG voted to instruct the editor to use the terms document, element, attribute, and ordered forest as appropriate and to close this issue.
Section 6.3.1 Path and field grammars
HST asked whether we are committed to formalizing all of XPath. There was discussion. AB observed that you need XPath to explain key constraints properly, and noted that PW has a paper on this topic, to which we could perhaps refer; MSM pointed out that it's not on the final version of XPath. (Some despondency.)
HST suggested describing this section as an open function from a formalization of Xpath to a formalization of key/keyref constraints, rather than a full free-standing formalization of key/keyref.
This amounts to taking XPath as a black box. Since that's what the spec does, there's no reason not to do it here.
JR suggested that a full formalization of XPath might not bring us much insight.
ISSUE: what ought we to do about Xpath? In particular, how much needs to be formalized?
8 Index of notations Some symbols are missing: turnstile, horizontal bar. The intention is to be complete (i.e. these are not intentional omissions.) ISSUE (editorial): list in index of notations should be complex.
Appendices.
After discussion, the WG confirmed (or possibly extended) a sentiment expressed at the Menlo Park face to face.
RESOLVED: MSM to roll the contents of appendices A and B into the CR comments list; Appendices A and B to be deleted; Appendix C to be retained and brought up to date.
In its teleconference of 2001-03-15, the WG voted to close this issue on the grounds that the problem had been resolved by the revision of the document.
ISSUE: Appendix C should describe infidelities vis a vis CR not vis a vis last-call draft.
Issues against the document as a whole. No candidate issues were raised. JT asked about versioning; will the HTML contain new material? No: the version available on Monday will be editorially the same as the draft of 3 November. There was some interest in seeing some of the pending editorial corrections and additions made, if possible.
RESOLVED: to request the editors to provide a version with whatever improvements in internal consistency and reductions in infidelities to the normative part of the spec they can manage by Wednesday 10 January.
In its teleconference of 2001-03-15, the WG voted to instruct the editor to add items for any further discrepancies between this document and XML Schema which may come to their attention and to close this issue.
ISSUE. The collision between the interpretation of a/b in XPath (an element of type b inside an element of type a) and that given here (an element of type b local to top-level complex type a) also seems unfortunate; it would be better if the short forms avoided such collisions.
On 2001-04-19 the WG agreed to split the description of normalized universal names off into a different document, and to move these issues to a different issues list.
ISSUE. Strictly speaking a model group does not include attributes; it is very confusing for terms with well established meanings to be used with new meanings. Get a new term.
Should this document be modified to align it better with the XML Query algebra?
Should the document be renamed from MSL to something else?