W3C home > Mailing lists > Public > public-swbp-wg@w3.org > October 2005

Re: Review of XML Schema Datatypes in RDF and OWL

From: Jeremy Carroll <jjc@hpl.hp.com>
Date: Thu, 27 Oct 2005 16:09:28 +0100
Message-ID: <4360EDA8.10409@hpl.hp.com>
To: ashok.malhotra@oracle.com
CC: public-swbp-wg@w3.org, w3c-xsl-query@w3.org

Hello Ashok

this is a delayed replied to your message

apologies for the delay.

We are now preparing the next draft of this document, which will
probably be a Working Group Note.

The latest editors' draft has two variations, depending on a WG decision
that will be made at our F2F on Friday/Saturday 4th/5th November.

The variants are:

There is a version with both sets together
and one with the deleted text as well

This version reflects my own position only, in that neither my co-editor
nor the WG have had time to review the changes.

This response is based on that version, and so is similarly has not been
endorsed as a WG response.


To summarize what the new version does, is that it makes the decisions
about which URIs to use for user defined datatypes, and about the
equality semantics, that the previous version discussed.

The SWBPD WG was happy with the editors' position on the first of these
issues (i.e. both XSCD and the use of the id attribute are appropriate).

The final decision on the second of these issues will be made at the F2F.

I personally am in the unfortunate position of representing an HP
position that favours
when I had previously indicated a personal preference for that expressed in
and also needing to articulate clearly to the WG the pros and cons of both.

In the remainder of this message, I will work through the change log
section concerning your message. I will also include parts of your
message for reference.

The pertinent changelog section is

Ashok:> Section 1.3

> This section refers to "derivation by list" and "derivation 
> by union".  This is, indeed, the XML Schema 1.0 usage but it 
> has caused widespread misunderstanding as the derived types 
> are not subtypes of the types they were derived from.  This 
> usage is being changed in XML Schema 1.1 to "constructed by 
> list" and "constructed by union".

Change log:
Deleted all uses of the word "derivation" in section 1.3

since it has caused confusion. Added links to the XML Schema document
for union, list and restriction, to make it clear that the intended
concept is "derivation" as defined by that document.

> Although it is not our place to make a recommendation here, a 
> couple of points need to be made.  The first approach speaks 
> about the using the URI "of the document".  This usage will 
> cause some members of the Schema WG extreme distress as they 
> take the position that Schemas are not isomorphic to 
> documents.  Thus, "schema target namespace" is recommended.

Change log:
Added brief discussion of target namespace after example 2A

providing further examples example 2B

and example 2C

Scoped this document to not address "XML Schema [...] assembled from
multiple schema documents". Added reference [XML SCHEMA1]

In the XML Schema Component Designator section

added more extended discussion of target namespace issue; and added
example XSCD for schema with target namespace.

I would find it helpful if you could have a quick look at the text
linked to from that change log entry. I have never used the target
namespace feature of XML Schema, and so was working from the XML Schema
1, XSCD, and the O'Reilly XML Schema book. In the process of making this
change I realised that this issue was more complicated than I had imagined.

> The use of fragment identifiers is non-standard.  Although 
> others use fragment identifiers in non-standard ways the use 
> needs to be clearly delineated.

Change log:

from C.2
Removed DAML+OIL solution
(this was the most clearly non-standard part)

from C.3
Added text showing how the @id solution

does comply with the secondary resource concept from RFC 3986, when read
in conjunction with RDF Concepts, XPointer and XML Schema.

In relation to:
>This usage will 
> cause some members of the Schema WG extreme distress as they 
> take the position that Schemas are not isomorphic to 
> documents.

I wonder whether the @id solution should explicit suggest that no target
namespace should be used, or perhaps that the target namespace should
explicitly be given by the retrieval URI of the document. The reading
being suggested, following RDF Concepts, section 7
is that the primary resource identified by the schema URI may be the
schema itself, (with the XML document being a representation of that
schema). The secondary resource, identified by the URIref, then has an
XML representation being the appropriate element of the XML document,
and may be the datatype itself.

As far as I could tell from the XSCD document discussion of schema
that the non-isomorphism problem which you mention, is not critical in
the easier cases; so I have tried to narrow the scope of this Note to
those easier cases; (and explicitly left the harder cases to the XML
Schema WG!)

> The SCDs approach is the approach favored by the XML Schema 
> WG and, although the fragment identifier approach is simpler, 
> please look at the latest SCD draft from XML Schema.  It is 
> possible that they may be willing to enter into a dialog and 
> make changes to the SCD draft to accommodate your needs better.

No change log entry.

Personal responses:
1) sorry for not having entered into such a dialog.
2) while the editors' opinion in the previous version expressed
a preference for the simpler solution, the replacement text:

2.4 Suggested Practice

When referring to arbitrary user defined datatypes in arbitrary XML
Schema, the [XSCD] solution is appropriate. When an RDF or OWL author or 
tool is writing an XML Schema for use with an RDF/XML document, the 
|@id| solution may be preferred.

tries to be more neutral.

> There is an extended disquisition on equivalence of values.  
> Not much new here.  But please look at the newly introduced 
> promotion scheme from xs:anyURI to xs:string.  Please also 
> note that xs:hexBinary can be cast to xs:base64Binary and 
> that comparisons on values of these two types can be made 
> after casting. 


Removed incorrect discussion of anyURI and string as being incomparable.

Changed example 3L

to be an entailment, since the anyURI is promoted to a string.
]] (xpath version only; in the other version eq is not discussed)

> 3.5 eq
> The document says that 'eq' returns 'true' or 'false' or that 
> the values are not comparable.  This is not the case.  The 
> 'eq' operator returns a type error if the values are 
> incomparable and returns the empty sequence if one or both 
> operands is the empty sequence.

Added "by throwing a type error" to description of |eq|
]]  (xpath version only; in the other version eq is not discussed)

Also note that the setup is such that the comparison being discussed
always compares sequences of length 1.

> The final example is incorrect "INF"^^xsd:float eq 
> "INF"^^xsd:float does return 'true'.

Deleted incorrect comment about INF eq INF.

> Please use the F&O functions to test for equality.

The version

does this, by deferring to the eq operator of xpath.

The version


does not, but does illustrate the use of SPARQL,
which then does use F&0



A further change made in response to your comment was in the 
acknowledgements section, thanks again.

Received on Thursday, 27 October 2005 15:10:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:44 UTC