W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2006

[Bug 2659] lc-2: simple barenames for schema component designators

From: <bugzilla@wiggum.w3.org>
Date: Thu, 05 Jan 2006 19:51:18 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1Eub8o-00087j-QG@wiggum.w3.org>


           Summary: lc-2: simple barenames for schema component designators
           Product: XML Schema
           Version: unspecified
          Platform: PC
        OS/Version: Windows 2000
            Status: NEW
          Severity: normal
          Priority: P2
         Component: SCDS: XML Schema Component Designators
        AssignedTo: holstege@mathling.com
        ReportedBy: holstege@mathling.com
         QAContact: www-xml-schema-comments@w3.org

raised on 31 Mar 2005 by Dan Connolly (connolly@w3.org):
Please allow barename fragments to be used as schema component designator
right hand sides. For example #over17 in


If they're already allowed, please make it more clear that they
are; my reading of

3.1 Schema Component Designator Syntax

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.



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

"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"/>

<daml:Class rdf:ID="Adult">
  <daml:intersectionOf rdf:parseType="daml:collection">
    <daml:Class rdf:about="#Person"/>
      <daml:onProperty rdf:resource="#age"/>
      <daml:hasClass rdf:resource="http://www.w3.org/TR/2001/NOTE-daml+oil-

 -- 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.              

There is an extensive discussion history on this:

The WG agreed to respond along the lines indicated by 2005Jun/0005.html, 
clarifying why the "simple barenames" solution did not work, when it was
reported that TAG discussions had lead to a belief that the request was not
for a reference to schema types, but for the abstract notion of a type in 
a namespace.  There were many responses to this, including:
* the SCD draft therefore had no relevance to this question, and we should
  respond accordingly
* the notion of a schema type unanchored to a schema was contradictory, and
  the examples adduced in the initial comment do not support the view that
  an unanchored notion of type is in play
* using a different syntax to refer to the abstract notion of type and a 
  specific type component in a schema would be unhelpful and confusing in 
* using the same syntax to refer to the abstract notion of type and a specific
  type component in a schema would be unhelpful and confusing in practice
* using a URI composed from a namespace URI and a schema component path to a 
  type is no different and no worse than using a namespace URI in the first
  place: if it dereferences to a specific component (or a specific schema) is
  not germane to its use as an abstract identifier
* and various other positions
Received on Thursday, 5 January 2006 19:51:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:04 UTC