W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > March 2003

LC Issue xmlsch-08 proposed response

From: Dave Beckett <dave.beckett@bristol.ac.uk>
Date: Tue, 25 Mar 2003 12:25:57 +0000
To: w3c-rdfcore-wg@w3.org
Message-ID: <29027.1048595157@hoth.ilrt.bris.ac.uk>

Deleting item 7 which I felt wasn't so helpful.

I would use this to respond to the submitted but the suggestion in
the last telcon was that I batch these responses up and send in one
go to match the pattern of the original email Although that will give
a huge message.




ISSUE http://www.w3.org/2001/sw/RDFCore/20030123-issues/#xmlsch-08

>    We believe there are probably good reasons for using an rdf:datatype
>    attribute, instead of re-using the existing xsi:type attribute which
>    has (when the type is defined in a schema defined by XML Schema 1.0)
>    the same semantics.In particular, rdf:datatype does not assume or
>    assert the existence of the type named as a type in a schema defined
>    by XML Schema, so it would be problematic to use xsi:type.
>    We do fear, however, that users are likely to find this
>    near-duplication of the meaning and function of xsi:type confusing. It
>    is not clear to us what, if anything, can or should be done to
>    minimize this danger.

The RDF Core WG has considered your this comment


and decided


to accept it and give the following explanation.

W3C XML Schema Datatypes in the schema documents

In W3C XML Schema (WXS), types are identified by XML qnames - the
simple types also have URIs, but that's not the crucial point here,
in WXS documents, they are given as XML Qnames.  These types or
references to user types can be explicitly used in the WXS documents
such as like this:

 <element name="comment" type="xsd:string"/>

 <attribute name="version" type="xsi:number" fixed="1.0"/>

 <restriction base="ex:BaseThing"> 

 <extension base="xsi:nonNegativeInteger">

here, using an XML schema simple datatype xsd:string with
declared earlier.

The 'type' and 'base' (there may be others) attributes take these
identifiers have xmlns="http://www.w3.org/2001/XMLSchema-instance"

type is the most common seen and usualy written as an attribute
xsi:type with xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

  xsi:type -  http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#xsi_type

so this is the potential attribute that could have appeared in
RDF/XML instance documents to say that a particular lexical form was
an XML schema datatype.

RDF Datatypes in instance documents

Example of the solution we chose

RDF datatypes are identified by URI-references and thus to indicate
that a piece of RDF/XML is a datatype, 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 is seen as an abbreviation or collapsed form, the former
the more general form.  The other things that can apply to literals
are the in-scope XML language:

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 element form.  Using it in the attribute form would have meant
all the attributes values were of the same datatype, not very useful,
wasn't proposed.  Thus a datatyped RDF literal is used in the
instance data in the element form with a new rdf:datatype attribute:

   <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

Now above deliberately didn't give an XML schema datatype URI in the
example above since it was agreed by the working group that any
datatype should be allowed (identified by a URI), not just the simple
XSD ones.

On the choice of attribute name, rdf:type was already used for the
class/instance relation and rdf:datatype was seen as adequate.

On using xsi:type in RDF/XML

Not in any particular order, but this is my summary of the main RDF
Core WG issues for the RDF/XML syntax on encoding datatypes using
xsi:type and why the rdf:datatype solution was used.

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 WXS
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 Tuesday, 25 March 2003 07:28:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:21 UTC