Editors: Asir S. Vedamuthu, webMethods and Mary Holstege, Mark Logic Corporation
This is the official pre-Last Call issues list for XML Schema Component Designators.
This document contains a list of issues regarding the XML Schema: Component Designators working draft. All comments or issues regarding the specification or this document must be reported to www-xml-schema-comments@w3.org (public archives).
An XML version of this issues' list is also available.
Color key: error warning note
| Id: Title | State | Type | Ack. |
|---|---|---|---|
| wd-3 : Readability - harder to identify edge-cases | no decision (raised) | clarification | |
| wd-1 : QA Editorial Comments | agreed | editorial | No reply from reviewer |
| wd-2 : Normative vs. Informative | agreed | editorial | No reply from reviewer |
| wd-4 : Incomplete Conformance Section | agreed | editorial | No reply from reviewer |
| wd-17 : SCP ambiguity, sigh | agreed | proposal | No response to reviewer |
| wd-5 : The schema designator URI should be dereferenceable | agreed | request | No reply from reviewer |
| wd-6 : The Schema URI SHOULD be used | agreed | request | No reply from reviewer |
| wd-7 : Compatibility with XPath | agreed | request | No response to reviewer |
| wd-8 : Drop or Change Query Use Case | agreed | request | No response to reviewer |
| wd-9 : Change syntax for model group step | agreed | request | No response to reviewer |
| wd-10 : Support for redefined component's predecessor | agreed | request | No response to reviewer |
| wd-11 : Specify a canonical namespace prefix? | agreed | request | No response to reviewer |
| wd-12 : Allow type(*) and element(*)? | agreed | request | No response to reviewer |
| wd-13 : Interaction of expanded traversals with // | agreed | request | No response to reviewer |
| wd-15 : Interaction of elided steps with extended traversals | agreed | request | No response to reviewer |
| wd-16 : Short for syntax for type(qname) | agreed | request | No response to reviewer |
| wd-14 : Interaction of elided steps with * | subsumed | request |
the documents seems to use a declarative style to define its requirements, although there is an occurrence RFC 2119 Keyword ("MAY") in 4.; the declarative style seems pretty appropriate to this abstract type of specification, but it makes it harder to identify edge-cases and error processing if applicable
- the EBNF in 4.1 seems to contradict the possibility of using the xmlns() scheme in the relative-schema- component-designator
- "schena" should read "schema" in 4.2.2
- the formatting of the TOC is done with ; please use the appropriate HTML markup instead (nested <ul> or <ol>)
- "Structurally, the first part looks like a URI, and the second part looks like an XPointer fragment identifier. An absolute schema component designator therefore is structurally a URI reference." -> why 'looks like' rather than 'is'? (at least, it should be either 'looks like' in all the cases, or 'is' in all the cases)
- splitting the bibliography into Normative/Informative references would be good
- I have some suspicion the document was produced with XMLSpec; could the XML version be provided as a non-normative alternative version to the doc?
the document doesn't distinguish normative from information sections; it would useful to do so to allow your readers to see where the requirements are set at first glance
- the conformance section is marked as "To be done"; does the WG has even a remote idea of what conformance to this specification would look like? if so, documenting this would be tremendously useful; e.g., is there any expectation to define an XML Schema Designator processor? or is it out of scope for this specification? what about XML Schema Designator generators (which, confusingly enough, would likely XML Schema processors)?
We discussed this case in passing at the F2F and I went away to determine what the facts of the case are. I can, sadly, report:
The path: /element(a)/element(b) could be either:
an abbreviation for /element(a)/type()/sequence()/element(b)
or:
element a's substitution group head.
Options:
(1) Accept it: c'est la vie It isn't as if /element(a)/element(b) mightn't ambiguously refer to multiple components. OTOH: The justification for elided steps is to be able to refer conveniently to content models. Pulling in substitution group heads seems like a very bad thing.
(2) Get rid of traversal over substitution group heads It's just one arc, we're not losing that much functionality. OTOH: it's just one arc, and special casing that one would be bad.
(3) Get rid of elisions They introduce ambiguity and lots of potential ambiguity and don't give us a lot more functionality than what we get with //. What's more, they violate any XPath expectations. OTOH: Lotsa folks like the simplicity of just navigating through the content model subgraph without having to type extra characters or think about the mechanics of the component model.
(3b) Get rid of unmarked elisions Not just elision, but some visible marker for the elision. This would do less violence to xpath intuitions and solve the ambiguity problem. OTOH: No clue what that syntactic marker should be.
(4) Recast syntax to arc based. (For default axes we can keep current spelling.) e.g. /element(a)/substitutionGroup(b) Solves the ambiguity problem, and lots of folks like the idea a priori anyway. Might be worth doing in any case, as certain aspects of the discussion of canonicals and // need to speak of arcs rather than just component types in any case. OTOH: Will require a fair amount of rework of the draft.
For myself, I'm all in favour of (3). It has always struck me as deeply wrong to have paths that left no syntactic mark that they were doing something magic. I could live with (4) as well, although the busy lazy person in me resists. 3b would be good if we could invent some good syntactic marker, but I cannot think what it should be.
I include (1) and (2) for completion, but I don't think either is a good solution.
(1) Shall we resolve the ambiguity in SCD syntax by adopting the alternative lexemes for non-default axes as indicated in the alternative SCD draft?
MSM: bumpersticker is "adopt the axis model" RESOLVED: adopt.
(2) Shall we additionally shift from a functional notation to an axis-style notation for steps?
MH: Editors say "no" but MSM says yes. RESOLVED: adopt axis syntax.
- 4.2.3 has "The URI on the left hand side of the schema component designator should be a URI of an actual document, in some media type. That media type should be some XML derivative, so that the XPointer framework applies." ; this seems very fuzzy: a URI is an identifier ; in this case, what it identifies would be a schema designator rather than "a document"; I think it should say "The schema designator URI should be dereferenceable ; if it is, the representation of this URI should be an XML document with a MIME-Type on which the XPointer framework applies"
"In the simplest case, where there is one root schema document, the URI of that document suffices" ; maybe a "SHOULD" for XSCD generators would be in order, with a reference to the WebArch principle, http://www.w3.org/TR/2003/WD-webarch-20031209/#uri-aliases
compatibility with XPath in the XSCD steps would be a big plus
On June 25th 2004, MSM suggested that wd-7 means syntactic and semantic compatibility with XPath. That is, our step types became new axis names, except that alone would leave different semantics. Semantic compatibility means providing a coherent answer for what do various steps mean when given both an XML document and a Schema component graph. Would there be explicit crossover steps? That is, navigate to an EII and the step into the schema component graph at the type for that element?
David Ezell: I would like to have a last call draft with notes inserted, showing the alternative syntax at each juncture point, so people can see that alternative option. If it doesn't take too many hours, a Working Draft (internal or public)... in analogy to how QT has recently done it's publication. Do people agree that we are finished? Do we consider the SCDs issue closed, modulo syntax issues? Yes. Closed!
Consider the axis style syntax proposed by Michael (3 for, none opposed, 7 abstain) That makes it editor's choice.
http://www.w3.org/XML/Group/xmlschema-current/SCD/scds.html still gives XQuery/XPath and XSLT 2.0 (QT) as possible users of the SCD's.
Given that the QT have NO current plans to use Component Designators shouldn't this use case be changed or dropped?
When we are building a component for a type Te which extends a base type Tb, we need to make the content model of Te consist of a sequence with two children: the content model of Tb, and then the content model appearing locally in the source declaration for Te. If I know that Te's content model has an outermost sequence, I can write /type(Tb)/sequence() -- if I know it's a choice, or an all, I write /type(Tb)/choice(), or .../all().
It would be convenient to be able to write something like /type(Tb)/model() and be done with it. (One drawback: that would presumably not be the canonical SCD for the model group in question.)
When we are handling redefinitions, it is convenient to be able to refer to the components which have been shadowed by the redefines.
Let's define a couple of terms. If schema document SD1 redefines schema document SD2, and SD1 contains a redefining source declaration for type Tr, then in schema(SD1) we'll have two components of particular interest, namely the 'new' Tr and the 'old' Tr. More precisely, the old Tr is what is denoted by /type(Tr) in schema(SD2), and the new Tr is denoted by /type(Tr) in schema(SD1). Let's define the terms 'predecessor' and 'successor': the old Tr is the predecessor of the new one, and the new one is the successor of the old one. (In Noah's account of redefines [1], each successor / predecessor pair forms a 'redeclaration prototype;.)
[1] http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Jul/att-0004/CompositionArchitecture.html
We have wondered in the past whether it's necessary to provide SCDs for the predecessors of redefined components. The more I think about it, the more I think it's probably worth doing just to ensure that we can talk about them when we need to. Note also that since the predecessor must have a successor of its own, we need to be able to handle arbitrarily long chains of predecessor links.
On the graph-model view of component structure, defining SCDs for predecessors is just a question of convenience. On the tuple view, it's essential, because without a SCD a successor can't point to its predecessor.
In section 4.3.1 of my paper, http://www.w3.org/2004/07/msm/rq-151.notes, I use the notation munge(...) to denote predecessors: the predecessor of type /type(Tr) is munge(/type(Tr)), and its predecessor is munge(munge(/type(Tr))) and so on. This isn't a terribly serious proposal; if I had been thinking harder I would have done something more like the rest of our syntax, and if I had been making a serious proposal I would have found a word other than 'munge'.
Agreed. The canonical (and only) SCP for the pre-redefined type named foo will be /type(foo)/type(). Redefined attribute group definitions and model group definitions have no predecessor in the component graph, and therefore will have no SCP.
Shall we specify --A-- specific namespace prefix for the canonical path syntax? Say, 'ns'. Example, /ns:po/@orderDate
Per the current draft, * is an abbreviation for any step in a schema component path. Should we allow * as an abbreviation for any QName in type(*), element(*), etc.?
Given expanded traversals, adding // to a path pretty much pulls in everything in the schema. This isn't very useful. For example, consider
/type(a)//element(b)This means any element b anywhere linked indirectly with a: element b in the content model of a, or in the content model of the base type of a, or in the content model of the base type of the base type of a, or in the content model of the base type of an element in the content model of the base type of a, or...
It seems that // is too broad: should we restrict it to only certain traversals; if so which ones? (Suggestion: the default traversals.)
The rules for elided steps, as written, allow the base type to be elided in a path. Do we really want this?
/type(a)/element(b)This refers to any element b in the content model of a, but if the base type step is elided, this can also mean any element b in the content model of the base type of a. Good? Bad?
We have short forms for element(qname) (qname), element(*) (*), attribute(qname) (@qname), and attribute(*) (@*). It would be good to have a short form for type(qname) and type(*) as well.
Given expanded traversals, adding * to a path pulls in a lot of stuff, and it isn't clear it is useful. For example, consider:
/type(a)/*This refers to any component referenced by a. If steps are elided, it could mean any component referenced by any component in the model group of a. Or (see wd-15) any component referenced in the content model of a base type of a. In most cases the possibility of elided steps will expand the applicability of * in ways that probably aren't useful. Suggestion: restrict interaction of * with elided steps, or require explicit marker (//) for elided steps.
Last update: $Date: 2005/03/11 13:35:54 $
This page was generated as part of the Extensible Issue Tracking System (ExIT)
Copyright © 2003, 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.