SCDs: Last Call Issues

lc-1: rfc2396bis [link to this issue]

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
             

Transition history

raised on 30 Mar 2005 by Chris Lilley (chris@w3.org)

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.

Acknowledgment cycle

Not started

Action history

lc-2: simple barenames for schema component designators [link to this issue]

  
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.              
              

Discussion history

1 Apr 2005, 22 Apr 2005, 29 Apr 2005, 6 May 2005

Transition history

raised on 31 Mar 2005 by Dan Connolly (connolly@w3.org)

Action history

lc-3: QA review of XML Schema: Component Designators [link to this issue]

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

Transition history

raised on 21 Apr 2005 by Dominique Hazaël-Massieux

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.

Acknowledgment cycle

Not started

Action history

lc-4: LC comments [link to this issue]

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.   
  

Transition history

raised on 26 Apr 2005 by Jeremy Carroll

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.

Acknowledgment cycle

Not started

Action history

lc-5: Rule out default namespace [link to this issue]

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

Transition history

raised on 29 Apr 2005 by Henry Thompson