W3C home > Mailing lists > Public > www-rdf-comments@w3.org > January to March 2003

Re: [closed] RDF Core LC issue xmlsch-08

From: Noah Mendelsohn/Cambridge/IBM <noah_mendelsohn@us.ibm.com>
Date: Mon, 31 Mar 2003 21:54:22 -0500
To: Dave Beckett <dave.beckett@bristol.ac.uk>
Cc: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>, w3c-xml-schema-ig@w3.org, www-rdf-comments@w3.org
Message-ID: <OF1F7C7474.B6EC5188-ON85256CFB.00105F25@lotus.com>

Out of curiosity, does this resolution allow one to also specify xsi:type? 
 To the extent one wants to be able to view an RDF document as also being 
XML, this would seem to be a desireable capability.  For example, I expect 
it would trigger type assignment in XPath 2.0 and XML Query.   Can one 
specify both in the case that a schema type is used?  Thanks.

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

Dave Beckett <dave.beckett@bristol.ac.uk>
Sent by: w3c-xml-schema-ig-request@w3.org
03/27/2003 06:27 AM

        To:     "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
        cc:     w3c-xml-schema-ig@w3.org, www-rdf-comments@w3.org, (bcc: Noah 
        Subject:        [closed] RDF Core LC issue xmlsch-08


The RDF Core WG has considered your last call comment captured in


(raised in section "4.1. Manifest typing in the instance (policy)" of
http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0489.html )

and decided


to accept it.

The RDF Core WG agrees that there are good reasons for not using
rdf:datatype rather than xsi:type.

We agree with the XML Schema WG that one reason is that RDF is not
restricted to using datatypes defined by XML Schema, but allows other
datatypes conforming to the XML Schema model for datatypes.

Another reason is that no other RDF/XML attribute takes QNames as
arguments.  Allowing this in one specific case is also likely to
cause confusion.

Whilst RDF Core would have preferred to not to introduce a different
attribute, it's judgement was that the solution proposed in the last
call drafts is the best of the options available.

To minimise any confusion, RDF Core has carefully described the
correct syntax in both the primer and the RDF/XML syntax documents.
We further note that incorrect use of xsi:type where rdf:datatype
should be used will be recognised as a syntax error by RDF/XML parsers.

Please reply, copying www-rdf-comments@w3.org whether this response
is an acceptable disposition of your comment.

Further, more detailed, informal explanation is given below.  We
assume familiarity with XML Schema datatypes :)


RDF Datatypes in instance documents are described in general terms in
the section
   Typed Literals - rdf:datatype

RDF datatypes are identified by URI-references and thus to indicate
that a piece of RDF/XML is a datatyped literal, you need to give the
URI somewhere.  Existing (untyped) literals are used like this:

As element content:

As attribute content:
    <ex:Node ... ex:prop="foo" ... />

The latter can be considered as an abbreviation of the former form.
The other things that can apply to RDF literals are the in-scope XML

As element content:
    <ex:prop xml:lang="en">foo</ex:prop>

As attribute content:
    <ex:Node ... ex:prop="foo" xml:lang="en" ... />

(of course xml:lang can be on any outer element)

So it was natural to allow datatypes by creating an extra attribute
in the property element form.  Using it in the attribute form would
have meant all the attributes values were of the same datatype (not
so useful) and wasn't proposed.  Thus a datatyped RDF literal is
used in the instance data in the element form with a new rdf:datatype

    <ex:prop xml:lang="en" rdf:datatype="http://example.org/dt">foo</ex:prop>
    <ex:prop rdf:datatype="http://example.org/dt">foo</ex:prop>

(Note, whether xml:lang values applies to such datatypes/is involved
in the datatype mapping is another issue, please don't get

The above didn't use an XML schema datatype URI in the example above
since any datatype is be allowed (identified by a URI).

Not in any particular order or necessarily complete, but here is a
summary of some issues that RDF Core considered for the RDF/XML
syntax on encoding datatypes using xsi:type and why the rdf:datatype
solution was decided.

1. xsi:type content is an XML Qname not a URI

Thus cannot indicate any arbitrary datatype URI reference, so another
attribute would be needed for that case (like rdf:datatypeURI) -
adding two attributes would be worse than adding one.

2. XML Qname attribute content in RDF/XML

This would be the first attribute in RDF/XML to take a XML Qname
value (a big step).  This would require extra explanation so that
existing users wouldn't confuse them with those that took URIs.

3. Namespace declarations, prefixes

It would also require instance documents to declare the xsi namespace
prefix and have to also check for any namespaces declared inside such
xsi:type values and declare those too - again new implementations and
explanation needed.

4. xsi:type would be confused with rdf:type

Since the former takes Qnames and the latter URI references, it would
be possible to get the name wrong and be confused at the errors.
Although xsi:type wouldn't be legal everywhere rdf:type was, rdf:type
would have been allowed on elements that took xsi:type.

5. confusing URIs and Qnames

A bad choice of namespace prefixes might make cause other problems in
xsi:type values, confusing them for URIs.  It would also be more than
likely that people would try to use Qnames in rdf:type attribute values.

6. xsi:type is illegal in RDF/XML now, unlikely to be used accidently

If somebody was tempted to use xsi:type, it would likely cause the
parsing to fail.  It is only ever used as an attribute in XML Schema
documents and to use it on a literal in RDF/XML would be something
like this:

      <ex:prop xsi:type="xsd:string">foo</ex:prop>

which is forbidden by grammar production
Received on Monday, 31 March 2003 22:00:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:02 UTC