Editors: Asir S. Vedamuthu, webMethods and Mary Holstege, Mark Logic Corporation
This is the official 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 | Open actions | Ack. |
---|---|---|---|---|
lc-1 : rfc2396bis | agreed | editorial |
| No response to reviewer |
lc-3 : QA review of XML Schema: Component Designators | agreed | editorial |
| No response to reviewer |
lc-4 : LC comments | agreed | editorial |
| No response to reviewer |
lc-2 : simple barenames for schema component designators | no decision (raised) | proposal |
| |
lc-5 : Rule out default namespace | no decision (raised) | proposal |
the <a href="http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html"> update to RFC2396</a> Now that RFC 3986 has been published, please remember to update this to <a href="http://www.ietf.org/rfc/rfc3986.txt">RFC3986</a> at the next revision. You might also consider whether the IRI to URI conversion described in section 3.1 of RFC 3987, which replaces the copy-and-past versions found in assorted W3C specifications including the Schema definition of anyURI, should also be referenced. http://www.ietf.org/rfc/rfc3987.txt
ACTION 20050429-03: Editors to start drafting responses to comments and updating SCD draft as appropriate, bringing substantive issues to WG as necessary.
Editors to start drafting responses to comments and updating SCD draft as appropriate, bringing substantive issues to WG as necessary.
It's partly based on the QA specification guidelines [1]. A) Section 3.1 EBNF notation of the Schema Component Designator Syntax directly links the definition of URI to RFC 2396 [2]; I think this is problematic for various reasons: * RFC 2396 has been obsoleted by RFC 3986 * I think given past experiences with URIs, giving more details as to what exact type of URI is allowed would be good; I guess what is really meant is the "absoluteURI" construction, but I'm not really sure. B) section 3.2 links to RFC2396bis, which is now RFC 3986 C) section 4.1 reads "This is because we cannot distinguish between individual annotations". I think the "we" is misplaced here. D) The definitions of the designators (absolute, canonical, relative) should use the verb "identify", since that's what URIs do; e.g. absolute schema component designator An absolute schema component designator identifies a particular component of a given assembled schema; it consists of two parts: a designator for the assembled schema (a schema designator), and a designator for a particular schema component or schema components relative (a relative schema component designator) to that assembled schema. E) The conformance section has a subsection entitled "Schema Component Designator Conformance", while it in fact defines conformance for Schema Component Designator processor. Also, it mentions the "behavior defined in this specification", while no behavior has been defined. I suggest instead: "must identify the schema component as defined in this specification" (see also XPointer terminology [3]) Maybe defining conformance for the designator itself is a good idea too; but it isn't done in the spec as of today. F) The references section doesn't follow the guidelines from the Manual of Style [4], nor are the labels defined in the references section used anywhere in the prose. G) XSCD obviously re-uses the XPath syntax spirit; could some of the definitions re-use (at least partially) their XPath counterpart (e.g. for step, axis)? H) Are there been any attempt at validating the EBNF proposed in the text to ensure it is correct? e.g. to validate the examples of XSCD given in the document I) one of the requirements state "it should be possible to designate any schema component within a schema. However, some exceptions will be made for certain of the helper components."; I haven't seen (but maybe have I missed it) an assessment of what exceptions have been made; also, I'm interested to know whether the fact that the requirement has been met has been formally proved. (not that I doubt it does, but since going to Last Call means having met the initial requirements, I'm curious to know whether this has been proved or only believed to be true) J) SpecGL suggests having the following information as part of your conformance clause: * what type of wording is used for conformance requirements, and how to distinguish them from the rest of the text; I have to say I can't really tell what the conformance requirements are in the current text, so you may want to consider making it clearer * are any of these conformance requirements optional? I don't think so, but you may want to clarify that as well * is the proposed syntax extensible (e.g. using new axis names)? Again, I don't think it is, but clarifying it may be helpful Dom 1. http://www.w3.org/TR/qaframe-spec/ 2. http://www.ietf.org/rfc/rfc2396.txt 3. http://www.w3.org/TR/2003/REC-xptr-framework-20030325/#terminology 4. http://www.w3.org/2001/06/manual/#References
ACTION 20050429-03: Editors to start drafting responses to comments and updating SCD draft as appropriate, bringing substantive issues to WG as necessary.
Editors to start drafting responses to comments and updating SCD draft as appropriate, bringing substantive issues to WG as necessary.
Comments on XSCD http://www.w3.org/TR/2005/WD-xmlschema-ref-20050329/ Hi A fine document. I was asked by the Semantic Web Best Practices and Deployment WG to review your document. Unfortunately I was tardy in my review, and the WG has not had time to consider my comments (only a few of which are specific to SWBPD WG concerns, particularly: #j100, #j062, #j020, #j110 below). Thus these remain personal comments, and not WG consensus comments. I would suggest that if it becomes important as to whether any specific comment has SWBPD WG consensus that the XML Schema WG could ask directly. As a participant in the I18N IG, I have also drawn the attention of I18N Core WG to comment #j050. As well as the comments below, I also have a question, which I hope for a quick answer to, since I may make further comments in response: The question is: Some of the examples show the use of a namespace prefix in a component designator, others omit the namespace prefix. Please summarize when the namespace prefix is necessary, and when it can be omitted. (Related comment #j090) My comments are: (numbered for convenience, non-consecutively) #j010 Section 1, final number list, points 3, 4 and 5. I found these slightly opaque, which is unsurprising. I wondered if it would help to appropriately hyperlink into other documents, for example, XML Schema 1; for example with terms, "locally scoped element", "anonymous type definitions", "redefinitions". #j020 Section 2.2 Other, 3rd Bullet Suggest expand "RDF assertions about types, etc." to two bullets e.g. [[ + Using XML Schema simple types as the datatype of RDF Literals + Describing XML Schema Components within RDF, including the use of XML Schema simple types as RDF classes ]] #j030 Section 3, eighth para, "a missing component cannot be used .." suggest hyperlinking "missing component" to somewhere else (maybe XML Schema 1) allowing the interested but ignorant reader (such as myself) to better understand this issue. #j040 Section 3, final para before 3.1 "It must not be used .... schemes" seems too strong. Suggest weakening to "It is not designed to be used ..." (A future XPointer scheme may be designed to work in combination with xscd) Also unclear whether the "must" has RFC 2119 force or not. #j050 Section 3.2 first para, and normative refs Suggest update ref to RFC 2396bis with ref to RFC 3986, or maybe 3987, since the names of schema components can and often do use characters outside the ASCII set supported by 3986, and the IRI RFC (3987) is closer to the xs:anyURI type (minor differences to do with spaces etc) #j060 Section 3.3 Two comments: #j061 Suggest adding text "(see section 4.4)" useful for people using a printout of this document rather than the hypertext version. #j062 "cannot be used" is too strong see section 6 of RFC 3986 In particular, RDF implementations would be likely to compare using simple string comparison. #j070 Section 4.1 first para "An assembled schema consists of a graph" Suggest clarifying the nature of the graph e.g. "rooted directed acylic graph" (I am not sure if this is true) probably avoiding issues to do with whether the graph is labelled or not. #j080 Section 4.1 end, defn of default axis On first reading this is surprising since one expects a single default. Suggest adding "Appendix A includes a summary of which default applies when." #j090 Section 4.2, second line The syntax shows ns-prefix as obligatory, but many of the examples omit it. Suggest the syntax should be modified to acknowledge that there is not always an ns-prefix. #j100 Section 4.2 near beginning. "in the context of an XML document .." Suggest following change: [[ in the context of an XML document the namespace prefixes will be bound in the conventional way (using the [in-scope namespaces] property of the element information item); other host languages will define their own namespace binding rules ]] to [[ in the context of an XML document the namespace prefixes will usually be bound in the conventional way (using the [in-scope namespaces] property of the element information item); other host languages and some XML applications will define their own namespace binding rules ]] rationale: within RDF/XML the use of the in-scope namespace prefixes is likely to be problematic. #j110 I find it slightly confusing what is the secondary resource identified by these fragIDs. Section 2.2 seems to suggest that types (etc) are identified. Whereas section 6 seems to suggest that type definitions (etc) are identified. I found Michael Sperberg-McQueen's presentation to the SWBPD WG in Boston useful in this regard, particularly the discussion of the compositional and explicit semantics behind the scheme.
ACTION 20050429-03: Editors to start drafting responses to comments and updating SCD draft as appropriate, bringing substantive issues to WG as necessary.
Editors to start drafting responses to comments and updating SCD draft as appropriate, bringing substantive issues to WG as necessary.
Please allow barename fragments to be used as schema component designator right hand sides. For example #over17 in http://www.w3.org/TR/2001/NOTE-daml+oil-walkthru-20011218/daml+oil-ex-dt#over17 If they're already allowed, please make it more clear that they are; my reading of 3.1 Schema Component Designator Syntax http://www.w3.org/TR/2005/WD-xmlschema-ref-20050329/ is that they're not. We discussed this in March 2004... [[ DC: Most pressing use case is pointing at user-defined datatypes. First design that occurs to me is #sku. Why not? MSM: Multiple top-level symbol spaces. #sku could be type, element, attribute, notation, attribute groups, named model groups... DC: OK, so don't do #sku to do that. Advise users to not have two top-level things named the same. ... ]] http://www.w3.org/2004/03/02-tag-summary.html#abstractComponentRefs-37 There seems to be little or no acknowledgement of the case case of user-defined datatypes in OWL. The only thing I see is: "RDF assertions about types, etc". Please cite this section of the OWL recommendation among your requiremenets... "Because there is no standard way to go from a URI reference to an XML Schema datatype in an XML Schema, there is no standard way to use user-defined XML Schema datatypes in OWL." -- http://www.w3.org/TR/2004/REC-owl-semantics-20040210/syntax.html#2.1 And acknowledge this example from the DAML+OIL submission among your use cases: <xsd:simpleType name="over17"> <!-- over17 is an XMLS datatype based on positiveIntege --> <!-- with the added restriction that values must be >= 18 --> <xsd:restriction base="xsd:positiveInteger"> <xsd:minInclusive value="18"/> </xsd:restriction> </xsd:simpleType> <daml:Class rdf:ID="Adult"> <daml:intersectionOf rdf:parseType="daml:collection"> <daml:Class rdf:about="#Person"/> <daml:Restriction> <daml:onProperty rdf:resource="#age"/> <daml:hasClass rdf:resource="http://www.w3.org/TR/2001/NOTE-daml+oil-walkthru-20011218/daml+oil-ex-dt#over17"/ > </daml:Restriction> </daml:intersectionOf> </daml:Class> -- http://www.w3.org/TR/2001/NOTE-daml+oil-walkthru-20011218/#9 I still can't see why the design chosen in DAML+OIL shouldn't be standardized in the XML Schema Component designators spec, so as I say, please change the design too.
MH to draft note to DC to get clarification of requirement wrt barenames.
Whatever LHS we use, a problem arises -- namespace->as above, schema->identity pblms ... So we should draw up a by-cases analyses of how it doesn't work in each case. ACTION: MH to draft such an analysis
ACTION: MH to ask DanC if he thinks #foo:baz is a cool barename fragment
Wrt e.g. the example //quantity in section 4.2.17 the prose says "This path designates global or local element declarations whose local name is quantity" The use of the phrase "local name" introduces at least a confusion and at worst a big. I can't immediately detect whether you rule out using the default namespace (I think you should, because you _can't_ declare it using the xmlns() XPointer scheme), but lets suppose you did or do rule it out, then the above should read: "This path designates global or local element declarations whose name is 'quantity' in no namespace" or words to that effect
Last update: $Date: 2005/05/12 20:07:17 $
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.