W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > September 2001

2001-09-07#6: ns qualified parseType values

From: dehora <dehora@eircom.net>
Date: Fri, 14 Sep 2001 05:19:10 +0100
To: "W3C Rdfcore" <w3c-rdfcore-wg@w3.org>
Message-ID: <000001c13cd4$67ff6a50$01000001@MITCHUM>
"Prepare a proposal for namespace qualification values of rdf:parseType
attributes upon which the group can make a decision."

Forces:

parseType="Literal" is, in the of words the M&S, "a minimum-level
solution to the requirement to express an RDF statement with a value
that has XML markup. Additional complexities of XML such as
canonicalization of whitespace are not yet well defined. Future work of
the W3C is expected to resolve such issues in a uniform manner for all
applications based on XML."

Ongoing proposals in the wg may lead to the interpretation that the
fundamental representation of a literal is a Unicode string with
optional language tag upon which serializations might have to impose
syntactic constraints. This is not catered for in the current M&S XML
syntax.

There is interest in treating XML literal element content as something
other than well formed XML (such as infoset). There may be interest in
the future to  apply well known data types over literals.

Any future RDF recommendation should recognise practice, notably by the
DAML effort, which is using parseType as extensibility mechanism beyond
that mandated by the current M&S. Further the wg should indicate an
appropriate method for people wishing to extend parseType. 

Clearly, changes to the existing interpretation of the parseType
attribute value Literal will be backwards incompatible with current
processors and RDF-XML data modelling assumptions. Therefore, the
interpretations and reservation of both the attribute values Literal and
Resource must stand.

The following is the key text in M&S re RDF-XML parseType:

"(P203) The parseType attribute changes the interpretation of the
element content. The parseType attribute should have one of the values
'Literal' or' Resource'. The value is case-sensitive. The value
'Literal' specifies that the element content is to be treated as an
RDF/XML literal; that is, the content must not be interpreted by an RDF
processor. The value 'Resource' specifies that the element content must
be treated as if it were the content of a Description element. Other
values of parseType are reserved for future specification by RDF. With
RDF 1.0 other values must be treated as identical to 'Literal'. In all
cases, the content of an element having a parseType attribute must be
well-formed XML. The content of an element having a parseType="Resource"
attribute must further match the production for the content of a
Description element.

The RDF Model and Syntax Working Group acknowledges that the
parseType='Literal' mechanism is a minimum-level solution to the
requirement to express an RDF statement with a value that has XML
markup. Additional complexities of XML such as canonicalization of
whitespace are not yet well defined. Future work of the W3C is expected
to resolve such issues in a uniform manner for all applications based on
XML. Future versions of RDF will inherit this work and may extend it as
we gain insight from further application experience."


Proposed revised and extended wording. Please note that (p4) is largely
illustrative at this point and could reasonably be excised with the
other paragraphs remain in place:

(p1) The parseType attribute changes the interpretation of the element
content. 

(p2) It is recognized that parseType is useful as an extensibility
mechanism. The preferred technique to extend parseType is through the
use of qualified names, as discussed in the XML Namespaces
recommendation. The purpose of using namespaces to denote parseType
values is to allow extensions to be associated with a vocabulary or
schema. Note: the XML namespaces notion of default namespaces shall not
apply to parseType values, in precisely the same sense that default
namespaces does not apply to attributes. Unqualified values of parseType
must not considered to be in any namespace.

(p3) The non-namespaced values specified are 'Literal' and 'Resource'.
The values are case-sensitive. The value 'Literal' specifies that the
element content is to be treated as an RDF literal. The element content
is considered opaque: that is, it must not be interpreted or passed on
by an RDF processor as RDF. The element content however must be well
formed XML and there are syntactic constraints imposed by this
serialization [see fixme]. The value 'Resource' specifies that the
element content must be treated as if it were the content of a
Description element. The content of an element having a
parseType="Resource" attribute must further match the production for the
content of a Description.

(p4) The local part values specified are 'literal', 'resource' and
'canonical'. These three are bound to the RDF namespace [fixme]. By
convention, the prefix 'rdf' is used as the namespace qualifier,
although any prefix can be used. Future editions of this document may
add new local parts as deemed appropriate. The local part 'literal' has
the same interpretation as 'Literal'. The local part 'resource' has the
same interpretation as 'Resource'. The local part 'canonical' specifies
that the literal should be treated as canonical XML [see fixme];  fixme:
more+markup examples.

(p5) An RDF-XML processor encountering an unrecognised parseType value
must continue to behave as if that value was 'Literal'. Note: how XML
attributes which affect the interpretation of literals are passed along
is not specified in this document (xml:lang is another case in point).
Nonetheless processors which find unrecognised parseType values should
pass on the found parseType value rather than the default case
'Literal', where they are capable of doing so.

Bill de hÓra
Received on Friday, 14 September 2001 00:20:40 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:39:43 EDT