XML Schema Component Designators Review

Comments on XSCD

http://www.w3.org/TR/2005/WD-xmlschema-ref-20050329/


Summary:
- short proposed WG response, with one comment only
- short list of my personal comments that the WG may wish to endorse
- longer list of personal comments



Suggested WG response:
==============================
We congratulate the XML Schema WG on bringing this document to Last Call.
We do not have any comments that we think merit a significant redesign.

We have the following WG comment:

Section 4.2 near beginning.
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.

WG participants (notably Carroll, ...) will be making individual 
comments, we welcome queries from the XML Schema WG as to whether 
particular, difficult, individual comments have the support of
this WG.
==========================

Other comments the WG may wish to endorse include
  #j062
  #j020
  #j110

I am asking the I18N Core WG whether they wish to endorse
  #j050 (probably strengthened)



Additional comments (suggested as personal comments):

First a question, which I would hope for a quick answer to, since
I may make further comments in response:

   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.



#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" so 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.

Received on Thursday, 21 April 2005 15:44:51 UTC