- From: Martin Duerst <duerst@w3.org>
- Date: Tue, 01 Jul 2003 18:01:26 -0400
- To: Brian McBride <bwm@hplb.hpl.hp.com>
- Cc: Graham Klyne <gk@ninebynine.org>, Dan Connolly <connolly@w3.org>, w3c-i18n-ig@w3.org, "Ralph R. Swick" <swick@w3.org>, misha.wolf@reuters.com, Tim Berners-Lee <timbl@w3.org>, rdf core <w3c-rdfcore-wg@w3.org>
Hello Brian, Many thanks for your message summarizing the situation, and your proposals to move forward. At 16:25 03/07/01 +0100, Brian McBride wrote: >I'd like to bring a little framing to this discussion in the hope that >we can wrap this up by this week's RDFCore telecon on Friday. > > >From my perspective RDFCore has moved beyond the point where it is >seeking to consider improved designs. The time for that was before last >call. We are now checking for problems with the current design and its >specification. > >I have allowed (could I have stopped it:) some discussion of the merits >of proposal that Martin has made. This gave an opportunity for the WG >to recognise the merits of that design and say to the chairs - we messed >up - this design is much better - please give us the time to incorporate >it. That has not happened. > >So, discussion of the form "here is a better design" is out of order at >this stage. Such suggestions need to be made at an earlier stage in the >process. > >So we must now consider whether i18n are pointing to significant flaws >in the present design. > >If I have understood correctly, there are broadly two issues: > > a) a violation of an i18n design principle that there should be only >one way to represent text/markup with/without lang tags in RDF's >abstract syntax. > > b) that users will be surprised that xml:lang tags that are in scope >around a parseType='Literal' do not affect that literal. > >I note that in > > http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jun/0187.html > >Martin suggests that issue b) is "easily the most important one". > >Martin: To address issue a) as you would like will require significant >changes to the RDFCore specs which RDFCore is not persuaded would be >beneficial at this time. We could spend more time and energy on it, but >it seems to me that, given your statement of importance we should focus >our efforts on resolving issue b). > >Do you agree? Many thanks for your proposal. I definitely agree in the sense that whatever energy you/we have left should first go into solving b). For the record, I would like to remind you that issue b) came up as a change from your side long after last call, so the arguments about not changing the design after last call don't seem appropriate for this issue. Also, I do not exactly agree with your summary of the situation on a). First, my understanding was that the RDF Core WG was chartered with clarifying, and not with changing, RDF M&S. Several people have agreed in this discussion that RDF M&S says that simple text strings in places marked as parseType='Literal' are the same as plain literals. As far as I know, nobody has disagreed on this point. If anybody actually disagrees, please say so. Second, I am not at all sure that a) would require significant changes. Of course I'm not very familiar with your specifications, but the main thing that needs to be done is to say in the RDF/XML document that anything marked with parseType="Literal" that does not actually contain any XML markup is a plain literal. Here is my rough analysis of what it affected, and how much: Concepts and Abstract Syntax The section I have found that is affected is: 5. XML Content within an RDF Graph (Normative) (in the last call version, this uses the wrapper approach, so that may change or may have changed, but is independent of issue a) ), but actually the change may be purely informational, because currently, it just says "This typically originates from the use of rdf:parseType="Literal" in the RDF/XML Syntax [RDF-SYNTAX].", which means it does NOT say that all parseType="Literal" end up as XML literals. So it could be left unchanged, although it would be nice to give readers a clue that not everything marked as rdf:parseType="Literal" ends up as an XML literal. Semantics I have not found any occurrence of 'parseType'. Maybe I have missed some. But this document should not be affected. Primer For whatever reason, this does not mention rdf:parseType="Literal", which is a separate problem that should be fixed (but this can be done during CR). So this document is not affected by the changes Schema I have not found any occurrence of 'parseType'. Maybe I have missed some. But this document should not be affected. RDF/XML Syntax The sections that I have found that would be affected are section 2.8, and the start of section 6 (just before section 6.1) 7.2.20 Production parseTypeOtherPropertyElt also is affected materially, but no editing may be necessary. Probably a note in Section 8 saying that there are two alternatives for serializing plain literals would be appropriate. Test Cases I have looked at the tests in the zip file "approved_20030117.zip", which seem to be the tests corresponding to the last call publication. I have found 10 tests that mention parseType Literal. Out of these I have found 5 that need to be changed. The changes should in all cases be very simple, namely removing the XMLLiteral datatype from the N-triples result. See my list below. I might have missed something, but I hope that this can at least be useful for cross- checking. So my present conclusion is that changing the specs to solve issue a) for <foo parseType="Literal">some text</foo> and <foo>some text</foo> does not seem to be such a major undertaking. Unless I have missed something important, the changes should be rather easy to apply. The size of these changes also suggests to me that this is indeed not a fundamental design change, but a change of a detail of this design. What then remains of a) is the issue of the XML Schema string datatype. When Tim dropped in on a long conversation between Ralph and me, he immediately said that 'string' and plain literals should be unified. On several occasions, it has been suggested that this be dealt with in OWL (which requires applications to understand 'string' as one of only two datatypes). Regards, Martin. List of tests with parseType Literal: rdf-containers-syntax-vs-schema/test004.rdf: <rdf:li rdf:parseType="Literal">2</rdf:li> This needs to be changed! rdfms-empty-property-elements/error001.rdf: This is not legal RDF; specifying an rdf:parseType of "Literal" and an rdf:resource attribute at the same time is an error. <random:someProperty rdf:parseType="Literal" No change needed rdfms-empty-property-elements/error002.rdf: This is not legal RDF; specifying an rdf:parseType of "Literal" and an rdf:resource attribute at the same time is an error. <random:someProperty rdf:parseType="Literal" No change needed rdfms-empty-property-elements/error003.rdf: From the original RDFMS document, paragraphs 229-234 and production [6.12], last clause: rdf:parseType="Literal" is forbidden here since we're creating an additional resource node. <random:someProperty random:prop2="baz" rdf:parseType="Literal" /> No change needed rdfms-empty-property-elements/test003.rdf: An empty property element just gives an empty literal. Here we make the parseType explicit. <random:someProperty rdf:parseType="Literal"/> This needs to be changed! rdfms-empty-property-elements/test009.rdf: <random:someProperty rdf:parseType="Literal"></random:someProperty> This needs to be changed! rdfms-xml-literal-namespaces/test001.rdf: <my:Name rdf:parseType="Literal"> No change needed. (but needs change because it currently says: Treatment of namespaces that are not visibly used (e.g. rdf: in this example) is implementation dependent. rdfms-xml-literal-namespaces/test002.rdf: <dc:Title rdf:parseType="Literal"> No change needed. But same as previous. rdfms-xmllang/test001.rdf: In-scope xml:lang applies to rdf:parseType="Literal" <eg:property rdf:parseType="Literal">chat</eg:property> This needs to be changed! rdfms-xmllang/test002.rdf: In-scope xml:lang applies to rdf:parseType="Literal" <eg:property xml:lang="fr" rdf:parseType="Literal">chat</eg:property> This needs to be changed!
Received on Tuesday, 1 July 2003 18:15:23 UTC