- From: Brian McBride <bwm@hplb.hpl.hp.com>
- Date: Tue, 07 Oct 2003 16:12:59 +0100
- To: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
- Cc: www-rdf-comments@w3.org, W3C XML Schema IG <w3c-xml-schema-ig@w3.org>
Michael and colleagues, I would like to thank you for your efforts in reviewing our documents and in particular for the effort that has gone into producing the clear response we find at: http://lists.w3.org/Archives/Public/www-rdf-comments/2003OctDec/0011.html I am interpretting this message as accepting, though not always with enthusiasm, the RDFCore responses on these comments. I will deal with xmlsch-02 in a subsequent message. Please let me know if I have misunderstood. Brian C. M. Sperberg-McQueen wrote: > Colleagues, > > thank you for your careful responses to our various comments > on the last call version of various RDF documents. Attached > you will find an HTML document which contains (a) our original > comments, (b) your responses to them, and (c) our responses to > your responses. > > These responses were drafted by a task force and reviewed, > amended, and approved at the XML Schema WG meeting today. > In doing a final editing pass over the document, however, I > found a response from you to one of our issues which had been > missed in our earlier work; I have suppressed the answer > approved today by the WG given, since it was based on the > misconception that you had not in fact responded to that > comment. > > best regards, > > -C. M. Sperberg-McQueen > W3C XML Schema Working Group > > > > > ------------------------------------------------------------------------ > > > W3C XML Schema Working Group > > > Comments on RDF documents > > > ed. Charles Campbell, C. M. Sperberg-McQueen, Henry S. Thompson > > > 10 March 2003 > > ------------------------------------------------------------------------ > > * 1. Notes on RDF Primer <#id2612094> > o 1.1. Design question, complexity (substantive) [ > <#id2612137>xmlsch-01 > <http://www.w3.org/2001/sw/RDFCore/20030123-issues/>] > o 1.2. Whitespace handling (schema-related) [ > <#id2612494>xmlsch-02 > <http://www.w3.org/2001/sw/RDFCore/20030123-issues/>] > * 2. Notes on RDF Concepts and Abstract Syntax <#id2625316> > o 2.1. Mapping from lexical forms to values (schema-related, > terminological) [ <#id2625341>xmlsch-03 > <http://www.w3.org/2001/sw/RDFCore/20030123-issues/>] > o 2.2. Values without lexical forms (schema-related, > important) [ <#id2625483>xmlsch-04 > <http://www.w3.org/2001/sw/RDFCore/20030123-issues/>] > o 2.3. Lexical forms, strings, and character sequences > (schema-related, editorial) [ <#id2625889>xmlsch-05 > <http://www.w3.org/2001/sw/RDFCore/20030123-issues/>] > o 2.4. Strings for natural-language data (substantive) [ > <#id2626099>xmlsch-06 > <http://www.w3.org/2001/sw/RDFCore/20030123-issues/>] > o 2.5. Typos and minor editorial notes <#id2628802> > * 3. Notes on RDF Semantics <#id2628988> > o 3.1. The “meaning” of literals (editorial) <#id2629009> > o 3.2. Types as lexical mappings (schema-related) <#id2629144> > o 3.3. Miscellaneous editorial notes <#id2629294> > * 4. Notes on RDF/XML Syntax Specification (Revised) <#id2629549> > o 4.1. Manifest typing in the instance (policy) [xmlsch-08] > <#id2629592> > o 4.2. QNames (Editorial, but important) [xmlsch-09] <#id2630438> > o 4.3. Miscellaneous editorial notes <#id2630830> > o 4.4. Normative specification of XML grammar (policy, > substantive) [xmlsch-10, xmlsch-11] <#id2630936> > o 4.5. On the relation between RDF and off-the-shelf XML tools > (policy, substantive) [xmlsch-12] <#id2631691> > > ------------------------------------------------------------------------ > *NOTE:* > /[This document contains notes considered and approved by the W3C XML > Schema Working Group and transmitted to the RDF Core Working Group as > comments on the last-call drafts of various RDF-related documents, > together with the text of various responses to these issues transmitted > to the XML Schema WG in different email messages: > > * Jeremy Carroll to the XML Schema IG, 30 June 2003 > (http://lists.w3.org/Archives/Public/www-rdf-comments/2003AprJun/0295.html > and > http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Jun/0196.html) > * Dave Beckett to C. M. Sperberg-McQueen, 27 March 2003 (on > xmlsch-08) > (http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0592.html > and > http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Mar/0143.html) > * Dave Beckett to C. M. Sperberg-McQueen, 27 March 2003 (on > xmlsch-09) > (http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0593.html > and > http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Mar/0144.html) > * Dave Beckett to C. M. Sperberg-McQueen, 29 April 2003 (on > xmlsch-10) > (http://lists.w3.org/Archives/Public/www-rdf-comments/2003AprJun/0112.html > and > http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Apr/0299.html) > * Dave Beckett to C. M. Sperberg-McQueen, 29 April 2003 (on > xmlsch-11) > (http://lists.w3.org/Archives/Public/www-rdf-comments/2003AprJun/0114.html > and > http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Apr/0301.html) > * Dave Beckett to C. M. Sperberg-McQueen, 29 April 2003 (on > xmlsch-12) > (http://lists.w3.org/Archives/Public/www-rdf-comments/2003AprJun/0113.html > and > http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Apr/0300.html) > > / > /This version of this document also contains responses from the XML > Schema Working Group; these responses were considered and approved at > the XML Schema WG teleconference of 3 October 2003 and are herewith > transmitted to the RDF Core Working Group as replies to its request for > feedback on its resolution of the issues./ > $Id: xmlschema.rdf.comments.responses.html,v 1.2 2003/10/03 19:53:05 > cmsmcq Exp $ > The XML Schema Working Group congratulates the RDF Core Working Group on > progressing its several documents to Last Call; we apologize for the > late submission of these comments, and hope that they prove helpful. > Our comments include some which bear directly on the use of XML Schema's > simple types by RDF, to which we believe you wished us to give > particular attention. In the text which follows, these are labeled > “schema-related”. Some other comments, in contrast, relate to important > and difficult technical and policy questions relating to language design > and tool usage; these are labeled “policy”. We hope that you will give > these comments very serious consideration, but we do not pretend to any > special standing in raising them, other than as representative members > of the XML community at large. Finally, there are some other questions > which are not directly related to XML Schema or to XML in general, and > for which we therefore pretend to no particular expertise or standing, > but which we happened to notice and which we call to your attention, as > any technically minded reader might do, in the hopes that doing so may > be useful to you; these are labeled “substantive” or “editorial” as the > case might be. > > > 1. Notes on RDF Primer > > RDF Primer, section 2.4 Typed literals > http://www.w3.org/TR/rdf-primer/#typedliterals > > > 1.1. Design question, complexity (substantive) [xmlsch-01 > <http://www.w3.org/2001/sw/RDFCore/20030123-issues/>] > > The introduction of pairs consisting of a lexical form and a type (or, > strictly speaking, a lexical form and a type /label/) seems at first > glance to complicate the RDF model somewhat. We have had the impression > that in other parts of RDF, typing is handled by adding further arcs and > nodes. If the type of a resource is identified by having an arc labeled > /rdf:type/ from it to (the URI of) its (RDF) type, and if the type of an > arc is similarly identified by an arc, then surely a reason ought to be > given for shifting to a different method for typing literal strings. It > seems like a dramatic shift in the infrastructure of RDF, from > “everything is a node, an arc, or a literal value” to “everything is a > node, an arc, or a typed literal value”. Perhaps not quite so dramatic, > after all. But the question of design consistency remains: why not > “everything is a typed node, a typed arc, or a typed literal”? > *Response from RDF:* > > Our resolution is: xmlsch-01 as in 0252 with amendment. i.e. > The RDF Core WG interprets this comment as two questions and a comment: > > * 1) Why is the type of a literal not described using a property > arc, as is done for other literals? > * 2) Having introduced typed literal nodes, why not introduce > typed resource nodes and typed property arcs as well > * 3) The WG should provide a rationale for this design in the > specifications > > *Regarding question 1:* > This would require that literals be allowed as subjects of RDF > statements. This is not possible in current RDF/XML and would > require considerable change, beyond the scope of the WG, to support > it. Further it introduces problems of non-monotonicity in the > semantics. A property whose value is plain literal is currently > taken to denote a sequence characters. Adding a further statement > could change that value to, say an integer, invalidating previous > inferences and breaking a fundamental tenet of RDF. > *Regarding question 2:* > No requirement justified a change to the notion of a URIREF node or > an RDF arc. > *Regarding comment 3:* > Providing a rationale document to accompany the specifications would > certainly be nice to have, but the working group chose to spend its > writing resource on explanatory text and formal specification rather > than justification. We reject this comment on the grounds that the > specifications are not intended to provide a rationale. > > *Response from XML Schema* > > *On question 1*: Thank you; that helps clarify the design. > *On question 2*: In the final analysis this is your call and we > don't plan to lie down in the road over it. For the record, though, > we should record that we find your analysis unconvincing. The > introduction of typed literals introduces a new idea into RDF, and > it is obvious that this new idea has possible applications elsewhere > in the design space. Your response amounts to saying that you chose > not to work through the design implications of introducing this kind > of type labeling, because it seemed possible to get by without such > re-thinking. The result is that the new idea will continue to feel > incompletely integrated into RDF; it will feel like a patch added as > an afterthought rather than an integral part of the design. > *On comment 3*: We understand your desire not to work your editors > to death. Your one-paragraph response to question 1, however, does a > good job of clarifying the point that was obscure to us, and we > think it may not be beyond the wit of your editors to introduce its > substance into the text at some appropriate point. > *Overall*: we are not wholly convinced by your resolution of this > issue but do not wish to appeal to the Director on it. > > > 1.2. Whitespace handling (schema-related) [xmlsch-02 > <http://www.w3.org/2001/sw/RDFCore/20030123-issues/>] > > Some members of the XML Schema WG have expressed concern that XML > Schema's rules for whitespace handling may interfere with expected > behavior in other contexts. This may be the appropriate place to bring > this question up. > In brief, XML Schema's simple types each define a whitespace facet, > which governs the kind of whitespace pre-processing done by an XML > Schema processor before the lexical form is checked for type validity. > Since the point of whitespace normalization is to simplify subsequent > processing, the lexical spaces of XML Schema's simple types are (like > those in many programming languages) defined without reference to the > preceding whitespace normalization. Integers, for example, are > represented by sequences of decimal digits; sequences containing blanks > are not legal lexical forms for integers. Indeed, strictly speaking it > is only after the whitespace pre-processing is done that the XML Schema > processor can be said to be working with a lexical form at all. > For example, the integer type has a value of collapse for the whitespace > facet, which means leading and trailing whitespace is stripped, and > internal whitespace sequences are reduced to a single blank (x20) > character. In an XML document in which the element /exterms:age/ is > defined as having type /xs:integer/, the following instances of > /exterms:age/ will all be type-valid: > > <exterms:age>27</exterms:age> > <exterms:age> > 27 > </exterms:age> > <exterms:age> 27 </exterms:age> > <exterms:age> 2<!--* ha, ha, fooled your full-text indexer! > *-->7 </exterms:age> > > The input information set, in each case, contains a character > information item for “2” followed by a character information item for > “7”, with character information items for whitespace characters, and a > comment information item, present in some of the examples. In all cases, > the lexical form proper is the character sequence “27” (i.e. the > sequence of characters after white space handling, and ignoring > comments, processing instructions, entity boundaries, and other > distractions). This is a legal lexical form for an integer, so all the > examples are type valid. > Some members of the XML Schema WG have worried that it may not be > obvious that the whitespace processing is not part of the process of > checking lexical forms for type validity, but part of the process of > extracting the lexical forms from the XML information set presented to > the processor. If an RDF document contains > > <exterms:age> 27 </exterms:age> > > and a processor hands the contents of the element to a generic > type-checker for XML Schema's simple types, saying in effect “this > purports to be the lexical form of an integer; is that OK?”, that type > checker will be required (if it conforms to the XML Schema spec's > definition of the simple types) to say “no, the character sequence > ‘ 27 ’ is not a legal lexical form for an integer.” > It's not clear whether RDF, being type-system neutral, can directly > address this concern (e.g. by specifying that an RDF processor should do > the appropriate whitespace pre-processing, or by warning users that they > should not include vagrant whitespace in typed literals), or whether it > suffices for developers of RDF software with built-in support for XML > Schema's simple types to deal with it, e.g. by performing it themselves > before handing the resulting lexical form to a type checker. > As noted, some members of our WG feel that you need to be alerted to > this as a possible source of confusion and unexpected results. Other > members of the WG feel that it verges on disrespect to assume that you > need instruction on this point. We compromised by agreeing to point out > the issue to you, and to leave you to draw your own conclusions. > *Response from RDF:* > > The RDF Core WG resolved: xmlsch-02 addressed by msg-0097 where > msg-0097 is > http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003May/0097.html > and says > PROPOSE RDF Core accepts the comment xmlsch-02 and agree to add the > following test case: > > <rdf:Description rdf:about="http://www.example.org/a"> > <eg:prop rdf:datatype="&xsd;int">3</eg:prop> > </rdf:Description> > > Does not entail > > <rdf:Description rdf:about="http://www.example.org/a"> > <eg:prop rdf:datatype="&xsd;int"> 3 </eg:prop> > </rdf:Description> > > Moreover the following comment to be added to concepts: > > NOTE: In [XML Schema (part 1)], white space normalization occurs > during validation according to the value of the whiteSpace > facet. The lexical-to-value mapping used in RDF datatyping > occurs after this, so that the whiteSpace facet has no effect in > RDF datatyping. > > In fact more test cases were desired, and the test cases created are > currently awaiting final WG approval and can be found in: > http://www.w3.org/2000/10/rdf-tests/rdfcore/xmlsch-02/ > The Manifest file describes four tests showing that:: > > * A well-formed typed literal is not related to an ill-formed > literal. Even if they only differ by whitespace. > * A simple test for well-formedness of a typed literal. > * An integer with whitespace is ill-formed. > > The actual text corresponding to the agreed note is found at the end > of section 5 > http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#section-Datatypes > a certain amount of editorial descretion was taken to consolidate > notes concerning your comments. > The full note from the editors draft is: > > Note: When the datatype is defined using XML Schema: > ... > + In [XML-SCHEMA1], white space normalization occurs during > validation according to the value of the whiteSpace facet. The > lexical-to-value mapping used in RDF datatyping occurs after > this, so that the whiteSpace facet has no effect in RDF datatyping. > > *Response from XML Schema* > > Thank you for your reply. > The XML Schema Working Group is in agreement on one point of our > reply and divided in our opinion on a second point. > First, we are agreed that the position you sketch out is not a > source of logical inconsistency which will render your specification > meaningless or logically problematic. It is entirely possible for > you to handle whitespace in this way. > On the second point, our views are divided. > A minority of the Working Group believes that you have made a > reasonable design choice, given that RDF will only ever be produced > by and consumed by software, and that humans and issues of human > legibility are not and should not be matters of concern in your design. > A larger portion of the Working Group vigorously disagrees and > believes that for RDF processors to treat your two test cases > differently is to build into RDF a potential for astonishing users > and leading to unexpected results which will haunt you and your > users for years to come. In this view, it is not as a matter of > compatibility with XML Schema, but as a matter of common-sense > concern for your users that you should simply say that the > whitespace processing specified for the type in question should be > performed by any RDF processor. > *Overall*: we do not have consensus either to express satisfaction > with your resolution of this issue or to raise a formal dissent. In > the opinion of our chair, this means there is no formal dissent, but > he recommends that this point be listed during the review of formal > dissents as an issue on which there was not perfect consensus. > > > 2. Notes on RDF Concepts and Abstract Syntax > > > 2.1. Mapping from lexical forms to values (schema-related, > terminological) [xmlsch-03 > <http://www.w3.org/2001/sw/RDFCore/20030123-issues/>] > > In http://www.w3.org/TR/rdf-concepts/#section-Datatypes: > > A /datatype mapping/ is a set of pairs whose first element belongs > to the /lexical space/ of the datatype, and the second element > belongs to the /value space/ of the datatype: > > We agree that it is useful to define a term to denote such mappings; in > the interests of inter-specification consistency, we wonder whether you > would be willing to consider using the term /lexical mapping/, which we > are introducing in our forthcoming draft of XML Schema 1.1. The term > /datatype mapping/ seems unlikely to be usable in the XML Schema > specification, where it would suggest to some readers a mapping from one > datatype to another, rather than as here a mapping from lexical space to > value space. (XML Schema 1.0 got by without a term for this concept.) > *Response from RDF*. [see next section]. > > > 2.2. Values without lexical forms (schema-related, important) > [xmlsch-04 <http://www.w3.org/2001/sw/RDFCore/20030123-issues/>] > > In http://www.w3.org/TR/rdf-concepts/#section-Datatypes: > > * Each member of the value space may be paired with any number > (including zero) of members of the lexical space (lexical > representations for that value). > > The provision for values without corresponding lexical forms contradicts > an assumption to which the XML Schema spec appeals from time to time. > The lexical space of any simple datatype in XML Schema is the domain of > the type's lexical mapping; the value space is its domain. There are no > meaningless lexical forms in the lexical space of the type, nor are > there ineffable values in the value space. By eliminating values from > the value space (e.g. by setting minimal and maximal values), the type > definer may indirectly also eliminate lexical forms from the lexical > space; conversely, by eliminating some items from the lexical space > (e.g. by setting a pattern), the type definer may eliminate items from > the value space. > Are there crucial aspects of RDF which will break if the list item > quoted above is changed to read “paired with one or more members of the > lexical space”? > *Response from RDF:* > > We decided: > > PROPOSED to clarify xmlsch-03 xmlsch-04 pfps-13 based on the > proposal to close in > http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0368.html > > > i.e. > > PROPOSE > > * xmlsch-03 - we globally use the term lexical-to-value > mapping instead of datatype mapping or any other term > * xmslch-04 - we do not change the definition of value space > but add a note clarifying the relationship with XML Schema > datatypes. > > The new text can be found in the editors draft at: > http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-concepts-20030117/#section-Datatypes > and reads: > > *5. Datatypes (Normative)* > The datatype abstraction used in RDF is compatible with the > abstraction used in XML Schema Part 2: Datatypes [XML-SCHEMA2]. > A datatype consists of a lexical space, a value space and a > lexical-to-value mapping. > The lexical space of a datatype is a set of Unicode [UNICODE] > strings. > The lexical-to-value mapping of a datatype is a set of pairs > whose first element belongs to the lexical space of the > datatype, and the second element belongs to the value space of > the datatype: > Each member of the lexical space is paired with (maps to) > exactly one member of the value space. Each member of the value > space may be paired with any number (including zero) of members > of the lexical space (lexical representations for that value). > A datatype is identified by one or more URI references. > RDF may be used with any datatype definition that conforms to > this abstraction, even if not defined in terms of XML Schema. > Certain XML Schema built-in datatypes are not suitable for use > within RDF. For example, the QName datatype requires a namespace > declaration to be in scope during the mapping, and is not > recommended for use in RDF. [RDF-SEMANTICS] contains a more > detailed discussion of specific XML Schema built-in datatypes. > Note: When the datatype is defined using XML Schema: > > * All values correspond to some lexical form, either using > the lexical-to-value mapping of the datatype or if it is a > union datatype with a lexical mapping associated with one > of the member datatypes. > * XML Schema facets remain part of the datatype and are used > by the XML Schema mechanisms that control the lexical > space and the value space; however, RDF does not define a > standard mechanism to access these facets. > > *Response from XML Schema* > > Thank you; this looks better. > > > 2.3. Lexical forms, strings, and character sequences > (schema-related, editorial) [xmlsch-05 > <http://www.w3.org/2001/sw/RDFCore/20030123-issues/>] > > In http://www.w3.org/TR/rdf-concepts/#section-Datatypes: > > With one exception, the datatypes used in RDF have a lexical space > consisting of a set of strings. > > Since “string” is used as the local name for a particular simple type in > the XML Schema namespace, we believe it will be less confusing for > users, in the long run, if the lexical representations of > simple-datatype values are described not as “strings” but as “character > sequences”. > This comment also applies to other uses of the term /string/ to denote > the members of a lexical space. > *Response from RDF:* > > *RESOLVED*: do not accept xmlsch-05 > Rationale: It feels like a fairly extensive editorial change. Also > in the semantic web activity documents xsd:string is always refered > to in its qualified form, and so the possible confusion is diminished. > > *Response from XML Schema* > > Thank you; we believe you are making a mistake but we will not > insist on our suggestion. > > > 2.4. Strings for natural-language data (substantive) [xmlsch-06 > <http://www.w3.org/2001/sw/RDFCore/20030123-issues/>] > > In http://www.w3.org/TR/rdf-concepts/#section-Datatypes: > > * A /plain literal/ is a string combined with an optional > language identifier. This should be used for plain text in a > natural language. As recommended in the RDF formal semantics > [RDF-SEMANTICS], these plain literals are self-denoting. > > We do not believe that simple strings are likely to be adequate for the > representation of arbitrary natural-language text. Even in English, > natural-language utterances (such as this document) may need some degree > of inline markup for clarity and adequate presentation; in > natural-language utterances requiring bidirectional display or /ruby/, > the best authorities (including the W3C I18n Working Group) recommend > the use of markup within the natural-language utterance. We thus suggest > that you may wish to moderate this recommendation that natural-language > material be represented by literals. > This is not an area in which we claim particular technical expertise; we > merely call it to your attention in the hopes that doing so may be > useful to you. > *Response from RDF:* > > *RESOLVED*: to accept xmlsch-06, with revised wording as noted > > A plain literal is a string combined with an optional language > identifier. This may be used for plain text in a natural > language. As recommended in the RDF formal semantics > [RDF-SEMANTICS], these plain literals are self-denoting. > > after other changes the text now reads:[1 <#id2626289>] > > *Response from XML Schema* > > Thank you. This wording is better. > We believe (again, we claim no special expertise here and would > defer to the views of the Internationalization Working Group) that > you might usefully add a health warning here. For example > > ... This may, if necessary, be used for plain text in a natural > language, but in general this is not recommended; natural > language is usually better represented with a more elaborate > structure.... > > We hope that you will be persuaded to add a health warning, but we > do not believe this point is worth registering a formal dissent for. > > > 2.5. Typos and minor editorial notes > > In http://www.w3.org/TR/rdf-concepts/#section-Literal-Value, for “the > datatype mapping is applied to the pair form by the lexical form and the > language identifier” read “the datatype mapping is applied to the pair > form/ed/ by the lexical form and the language identifier”. > In the same section, for “Such a case, while in error, is not > syntacticly ill-formed ” read “Such a case, while in error, is not > syntactically ill-formed” (et passim). > In section http://www.w3.org/TR/rdf-concepts/#section-XMLLiteral, for > “root element tag” read “root element”. > In the same section, for “XML element content” read “XML data” (the term > /element content/ is used in some markup-related specs as a complement > of /mixed content/ to denote the content of elements which can contain > other elements but cannot contain parsed character data). > > > 3. Notes on RDF Semantics > > > 3.1. The “meaning” of literals (editorial) > > The meaning of a literal is principally determined by its character > string: it either refers to the value mapped from the string by the > associated datatype, or if no datatype is provided then it refers to > the literal itself, which is either a unicode character string or a > pair of a string with a language tag. > > Some members of the XML Schema WG are made nervous by the appeal to the > notion of “meaning” here. [N.B. our task force read this section out of > context, and were not aware of any foregoing elucidation. So this > comment may be out of place.] There is also some concern about the > apparent conflation here of the notions of /meaning/ and /reference/. We > wonder whether this discussion would be weakened by replacing references > to meaning and reference by references to denotation; we are inclined to > think it would be an improvement, but recognize that the RDF Core WG's > views may differ. > *Response from RDF:* None (unless overlooked). > *Response from XML Schema* > > We continue to believe this comment important, but are willing to > leave this to your editors' judgement. > > > 3.2. Types as lexical mappings (schema-related) > > A datatype is an entity characterized by a set of character strings > called lexical forms and a mapping from that set to a set of values. > > We have a couple of reservations concerning this characterization. > > * Elsewhere (e.g. in Concepts and Abstract Syntax, section 3.3, > http://www.w3.org/TR/rdf-concepts/#section-Datatypes), the RDF > specs say that there may be values in a value space which are not > in the range of the lexical mapping; we have suggested that if > possible those statements should be changed, but if they are > retained, then a datatype cannot be characterized solely by the > lexical space and the lexical mapping, because such ineffable > values appear in neither of these. > * The statement describes (with the exception of the problem just > noted) simple datatypes, but not the class of complex datatypes > which can be defined by XML Schema, nor all the types (or > type-like constructs) definable in various other schema languages > for XML. > > *Response from RDF:* None (unless overlooked). > *Response from XML Schema* > > The wording given in your response to xmlsch-04 (your section 5 of > RDF Concepts) seems to address these concerns adequately. Thank you. > > > 3.3. Miscellaneous editorial notes > > In http://www.w3.org/TR/rdf-mt/#dtype_interp, for “which we will refer > to as XSD and use the Qname prefix xsd:” read “which we will refer to as > XSD and denote using the Qname prefix xsd” (or something similar). > In http://www.w3.org/TR/rdf-mt/#dtype_interp: > > For example, XML Schema requires that the value spaces of xsd:string > and xsd:decimal to be disjoint ... > > This sentence is not exactly wrong, but it seems slightly unusual to use > the verb /require/ here, instead of /define/ or something similar. We > suggest recasting this as “For example, XML Schema defines the value > spaces of /xsd:string/ and /xsd:decimal/ as disjoint ...” (Note, for the > record, that the value spaces of all the primitive simple datatypes of > XML Schema 1.0 are pairwise disjoint.) > In , > > any literal of the form "sss"@ttt^^ddd, where /ddd/ is not > /rdf:XMLLiteral/, treated as identical to the same literal without > the language tag, "sss"@ddd > > is "sss"@ddd a typo for "sss"^^ddd? > In http://www.w3.org/TR/rdf-mt/#dtype_entail, for “it is valid to add > any number of leading zeros to any numeral and still be a correct > lexical form for /xsd:integer/”, perhaps read “it is possible to add any > number of leading zeros to any lexical form for /xs:integer/ without it > ceasing to be a correct lexical form for /xsd:integer/” > > > 4. Notes on RDF/XML Syntax Specification (Revised) > > RDF/XML Syntax, http://www.w3.org/TR/rdf-syntax-grammar/ > > > 4.1. Manifest typing in the instance (policy) [xmlsch-08] > > RDF allows /Typed Literals/ to be given as the object node of arcs. > These consist of a literal string (with optional language) and a > datatype RDF URI Reference. This is handled ... with an additional > rdf:datatype="/datatypeURI/" attribute on the property element. > > 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. > Response > <http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0592.html> > from RDF > > Colleagues, > The RDF Core WG has considered your last call comment captured in > http://www.w3.org/2001/sw/RDFCore/20030123-issues/#xmlsch-08 > <http://www.w3.org/2001/sw/RDFCore/20030123-issues/#xmlsch-08%0A> > (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 > http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0124.html > <http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0124.html%0A> > 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” > http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-datatyped-literals > > 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: > > <ex:prop>foo</ex:prop> > > 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 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 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 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 distracted!) > 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 > http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/#literalPropertyElt > > *Response from XML Schema* > > Thank you for your response; we regret to report that we are > slightly confused by it. > Is ‘The RDF Core WG agrees that there are good reasons for not using > /rdf:datatype/ rather than /xsi:type/’ a typo for ‘The RDF Core WG > agrees that there are good reasons for not using /rdf:datatype/ > rather than /xsi:type/’? If so, then the rest of the reply makes > more sense. > We are concerned, however, by point 6 in your informal response. It > seems problematic to us to make /xsi:type/ illegal in XML-encoded > RDF documents. Among other things, this would make it impossible to > validate documents with an XML Schema schema and later process them > with an RDF processor. > It is also not clear to us that you or we have fully addressed the > question of user confusion. The small string distance between > /rdf:type/ and /xsi:type/ is almost certain eventually to confuse > any user who must use both. Your analysis seems to us to indicate > only that you don't really expect any users to be interested in both > RDF and XML Schema; we don't think that such users are likely to be > all that rare. > But since we don't have any better solution to urge upon you, all we > can do is gloomily predict user confusion and hope for the best. > > > 4.2. QNames (Editorial, but important) [xmlsch-09] > > We were unable, on a first reading, to determine whether the default > namespace declaration, and thus unprefixed names, were or were not > allowed in order to encode 'RDF URI References'. Indeed the introductory > prose about QNames (2nd para of > [http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-intro]) does > not seem to connect up with the relevant (?) production in > [http://www.w3.org/TR/rdf-syntax-grammar/#section-Infoset-Grammar], > which we take to be > [http://www.w3.org/TR/rdf-syntax-grammar/#URI-reference]. > This can and should be cleared up. > Response > <http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0592.html> > from RDF > > Colleagues, > The RDF Core WG has considered your last call comment captured in > http://www.w3.org/2001/sw/RDFCore/20030123-issues/#xmlsch-09 (raised > in section "4.2. QNames (Editorial, but important)" of from > http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0489.html) > and decided > (http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Mar/0138.html) > to accept it giving the following explanation: > > The RDF/XML syntax WD section referred to is paragraph 2 of > http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/#section-Syntax-intro > is the very first section in the document introducing the syntax > intended as an overview, not defining the grammar. > > We accept that this paragraph could be misleading and imply that an > XML prefix, and thus only prefixed names, are required. > We propose to amend the text in that paragraph to make it clear that > in a XML QName the prefix is optional where there is a default > namespace either by adding a note or rewording to remove the mention > of prefixes. > However, we note, the link [Qnames] in the section above already > goes to the following definition of QName: > > QName ::= (Prefix ':')? LocalPart > Namespaces in XML > -- http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-QName > > which shows that the prefix part is optional in the current > definiton of QNames. > This is also mentioned in the errata: > > * "Names with no colon can be qualified names." Namespaces in > XML Errata -- > http://www.w3.org/XML/xml-names-19990114-errata#NE10 > > We also peeked at XML 1.1 CR: > > QName ::= PrefixedName | UnprefixedName > > Namespaces in XML 1.1, W3C Candidate Recommendation 18 December 2002 > http://www.w3.org/TR/2002/CR-xml-names11-20021218/#NT-QName > which keeps the same distinction. > Please reply, copying www-rdf-comments@w3.org indicating whether > this is an acceptable resolution of the comment. > > *Response from XML Schema* > > Thank you for the clarification. > > > 4.3. Miscellaneous editorial notes > > In > http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-empty-property-elements, > the sentence > > When an arc in an RDF Graph points to an object node which has no > further arcs, which appears in RDF/XML as an empty node element > sequence such as the pair <rdf:Description rdf:about="..."> > </rdf:Description>, this form can be shortened. > > seems less clear than it might be. Different readers prove to have > different views on what is meant by “the pair <rdf:Description > rdf:about="..."> </rdf:Description>”; perhaps it can be replaced by > something like “the empty element <rdf:Description rdf:about="..."/>” > without loss of precision? Perhaps the sentence could read > > When an arc in an RDF Graph points to an object node which has no > further arcs, which appears in RDF/XML as an empty node element such > as <rdf:Description rdf:about="..."/>, this form can be shortened. > > > 4.4. Normative specification of XML grammar (policy, substantive) > [xmlsch-10, xmlsch-11] > > We note with admiration the excellent tutorial introduction to the > striped syntax in Section 2 > [http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax]. We are less > happy with the nature of the syntax, and with the approach taken to its > normative statement > [http://www.w3.org/TR/rdf-syntax-grammar/#section-Infoset-Grammar]. > As regards the syntax itself, we would much prefer to have seen a move > to a single canonical syntax with much less variablity. With respect, > the current design suggests that the value of XML has been > misunderstood. The range of alternative forms of expression provided for > in the current design make it very difficult to use the broad range of > generic XML tools (e.g. syntax-directed editors, XSLT) which could give > so much benefit to RDF users. (More on this below.) At the very least we > would encourage you to specify a single canonical form, probably > strictly striped, which could be defined by an XML Schema or DTD. We > would be happy to work with you to develop a schema for such a subset. > As regards the approach taken to /defining/ the syntax, in our view, > layering of specs has very high value, and so defining an XML document > type by way of what is very nearly a character-level BNF is at best a > missed opportunity and at worst a serious mistake. It obscures the > important aspects of the document type behind a welter of irrelevant > detail about e.g. whitespace and start-tag/end-tag matching. It makes it > /very/ difficult for the reader to actually understand what is and isn't > actually allowed -- what an RDF/XML document actually /looks/ like. > Not only does this confuse levels and thus readers, it also runs the > risk of inadvertently defining an XML subset. It also appears, on a > strict reading, to rule out XML documents not derived from the parsing > of character streams as possible RDF/XML (so that it would be > illegitimate to regard a data structure created using a DOM interface, > for example, as RDF/XML). > The use of event-triggered data-model construction actions to specify > the relationship between XML representation and corresponding data > objects is innovative and compelling, but surely it would be > straight-forward to associate these events with a pre-order traversal of > an infoset independently constrained by a DTD, XML Schema schema or > other appropriate definition of the canonical document type. If > continued support for alternative forms is considered essential, then a > two-step approach where the semantics of any non-canonical form is > defined in terms of a canonical form to which it corresponds would still > be far simpler than the current approach. > *First response from RDF:* > > Dear Colleagues > The RDF Core WG has considered your last call comment captured in > http://www.w3.org/2001/sw/RDFCore/20030123-issues/#xmlsch-10 (raised > in section "4.4. Normative specification of XML grammar (policy, > substantive)" of > http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0489.html) > and decided > http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0361.html > to postpone it. > A canonical subset of RDF/XML was considered by the RDF Core WG. > However the WG believes that due to the way mixed namespaces are > used in RDF/XML it is not possible to define such a subset that: > > * a) can represent all the RDF graphs that RDF/XML can represent > * b) can be described by an DTD or an XML Schema. > > An alternative would be to define a new syntax that is describable > with a DTD or an XML Schema but doing so is beyond the scope of RDF > Core's current charter. We note that the XHTML WG have expressed > interest in working on such a syntax and have been encouraged to do > so by RDF Core. RDF Core also welcomes XML Schema's offer to help > with this work. > We will add this issue to the RDFCore postponed issues list at: > http://www.w3.org/2000/03/rdf-tracking/#rdfms-validating-embedded-rdf > Please reply to this email, copying www-rdf-comments@w3.org > indicating whether this decision is acceptable. > Thanks > Dave > > *Second response from RDF* > > Dear Colleagues > The RDF Core WG has considered your last call comment captured in > http://www.w3.org/2001/sw/RDFCore/20030123-issues/#xmlsch-11 (raised > in section "4.4. Normative specification of XML grammar (policy, > substantive)" of > http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0489.html) > > The main points you raised in this comment are: > > * > 1) RDF/XML is defined in "what is very nearly a > character-level BNF [which] is at best a missed opportunity > and at worst a serious mistake." > o obscuring important parts of the document type > o making it very difficult for the reader to actually > understand what is and isn't actually allowed. > o confusing layers > RDF/XML is entirely layered on the XML Infoset as defined in > Syntax Data Model > http://www.w3.org/TR/rdf-syntax-grammar/#section-Data-Model > and is not defined at the character-level. > All XML detail is handled by the XML specifications, not this > document - deployed RDF/XML applications are entirely built on > standard XML tools. In layering on the XML infoset, we leave > only the important parts of RDF/XML that users and application > writers need be concerned about - elements, attributes, > whitespace and text. > It would have been a mistake to gloss over where, say, the > whitespace was significant and where it was ignored - which > was one problem with the original RDF M&S specification. > * > 2) Rules out XML documents not parsed from character streams > (such as DOM) > This was explicitly called out: > > This model illustrates one way to create a representation > of an RDF Graph from an RDF/XML document. It does not > mandate any implementation method - any other method that > results in a representation of the same RDF Graph may be > used. > In particular: ... > o This specification does not require the use of > [XPATH] or [SAX2] > > http://www.w3.org/TR/rdf-syntax-grammar/#section-Data-Model > If a DOM interface can provide the very few (4) XML Infoset > Infoitems that are needed here, it is not ruled out. > * > 3) Suggests a two-step approach first mapping to canonical RDF > form constrained by DTD or XML Schema > An approach using a mapping to a canonical RDF written in XML > is related to issue xmslch-10 where we explain why we didn't > feel we could do this under the current charter. It certainly > would have been useful and helped. > The model and grammar used here closely matches how many > RDF/XML apps were written, in a token matching style that can > be used with standard syntax lexers and grammar generators. > This approach has proved suitable after other implementor > feedback. > > The RDF Core Working Group has decided: > http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0361.html > <http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0361.html%0A> > that the explanation above answers your comment as a clarification. > Please reply to this email, copying www-rdf-comments@w3.org > indicating whether this decision is acceptable. > Thanks > Dave > > *Response from XML Schema* > > Thank you. > We realize that this is a difficult area, but we believe that it > would be a mistake for W3C to move forward with a new version of the > RDF specifications without undertaking the work of a revision of the > syntax. > We regret that we must dissent formally from your resolution of this > issue. The current mismatch between RDF syntax and off-the-shelf XML > tools has not become easier to bear as time goes on; we believe it > must be addressed. > > > 4.5. On the relation between RDF and off-the-shelf XML tools > (policy, substantive) [xmlsch-12] > > With some diffidence, we conclude by raising what may be a sensitive issue. > It does not seem to us that the XML serialization of RDF shows RDF to > advantage. At the level of the underlying graph model, RDF information > has a simple and regular structure, which appears in the XML > serialization to be anything but simple and so irregular as to bring the > words “capricious” and “arbitrary” to the lips of unprejudiced > observers. Tastes in markup style differ, but we believe that the root > of the problem is the high degree of variability with which the same > underlying graph structures may be serialized, according to the rules > given in this document. > Owing in part to the variability itself, and in part to the specific > forms taken by that variability, it is not feasible to write an XML > Schema schema, or (if the comments in Appendix A.1 are accurate) a Relax > NG schema, or an XML 1.0 DTD, which defines the set of correct > serializations of correct RDF graphs. It is not convenient to run XSLT > processes over arbitrary RDF serializations, nor to query or process > arbitrary RD data using XQuery. Arbitrary RDF data is similarly > inconvenient for other standard XML tools to process. > There is, as a result, something of a cleft between the RDF community > and the set of RDF tools on the one hand, and the community of users and > tools employing what some have called /colloquial XML/. The parallel > development of query languages, schema languages, object models, APIs, > editors, display tools, and so on does offer relatively harmless ways > for a large number of people to employ their time, but it does not seem > to us to serve the larger Web community well. > The cleft between RDF and colloquial XML does not seem to us to be > required by the RDF data model. A graph in which nodes have certain > properties and arcs have certain properties is not, in itself, a > peculiarly difficult structure to render in XML or to process with > off-the-shelf XML tools. An XML vocabulary in which nodes may appear as > elements, or as attributes, or as attribute values, or as the PCDATA > content of elements, and in which property names may appear as three of > the same four constructs, on the other hand, seems a rather less > straightforward XML representation of the underlying graph structure > than most XML vocabularies for graphs have chosen. > The result is that not just arbitrary RDF data, but data encoded using > vocabularies defined in RDF terms (for which current W3C work provides a > number of examples), will be hard to process using off-the-shelf tools. > We believe this difficulty represents a lost opportunity, and we believe > the opportunity could readily be seized if the XML serialization were > modified to capture more of the regularity of the RDF data model. > We are ready to work together with the Working Groups in the Semantic > Web Activity and with other interested parties to formulate an XML > serialization which captures the information in the RDF model and which > is more readily amenable to processing with off-the-shelf XML tools. > *Response from RDF*: > > Dear Colleagues > The RDF Core WG has considered your last call comment captured in > http://www.w3.org/2001/sw/RDFCore/20030123-issues/#xmlsch-12 raised > in (XML Schema) section "4.5. On the relation between RDF and > off-the-shelf XML tools (policy, substantive)" > http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0489.html > and (Butler) > http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0531.html > and decided > http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Apr/0361.html > to postpone it. > The main points we felt you raised in this comment are: > > * > 1) RDF/XML > o doesn't match the RDF graph model well > o many ways to write things (elements, attributes, > attribute values , ...) > o cannot write a W3C XML Schema, Relax NG schema, XML 1.0 DTD > o "not convienient" to use XSLT, use XQuery, other XML tools > We know and could give you more problems. However we felt we > couldn't fix it all due to the charter constraint: > > [[The RDF Core WG is neither chartered to develop a new > RDF syntax, ...]] > > http://www.w3.org/2001/sw/RDFCoreWGCharter > Although we note, most of the above XML technologies mentioned > above are successfully used with RDF/XML. > So we propose to postpone dealing with this in this WG, > recording your comments for any future work. > * > 2) RDF and XML need not be on different paths > o models, QLs, APIs, editors, tools > o this cleft is not required > We encourage work to help integrate better but recognise this > is heading into larger web architecture issues. > * > 3) Propose that the XML serialization were modified to capture > more of the regularity of the RDF data model, offer help. > The WG notes your offer of help and has asked the semantic web > coordination group to carry it forward. > > We will add this issue to the RDFCore postponed issues list at: > http://www.w3.org/2000/03/rdf-tracking/#rdfms-validating-embedded-rdf > Please reply to this email, copying www-rdf-comments@w3.org > indicating whether this decision is acceptable. > Thanks > Dave > > *Response from XML Schema* > > None. (Note: owing to an error in preparing this version of this > document, the RDF Core response on this issue was missed and the XML > Schema Working Group did not have it in front of them when we > approved our responses. The editor of this document has unilaterally > suppressed the response originally drafted and approved, since it > was predicated on false assumptions.) > > ------------------------------------------------------------------------ > > > Notes > > [1 <#ref-to-id2626289>] Final text appears to have been omitted from the > RDF response by mistake. -MSM
Received on Tuesday, 7 October 2003 11:51:41 UTC