raised on 26 Apr 2005 by Jeremy Carroll:
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.   

agreed on 29 Apr 2005

ACTION 20050429-03: Editors to start drafting responses to comments and updating 
SCD draft as appropriate, bringing substantive issues to WG as necessary.