- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Wed, 12 Mar 2003 11:33:54 +0000
- To: Dave Beckett <dave.beckett@bristol.ac.uk>
- CC: Jeremy Carroll <jjc@hpl.hp.com>, w3c-rdfcore-wg@w3.org
Sorry I have not been sufficiently clear. Links included etc. Dave Beckett wrote: >>>>Jeremy Carroll said: >>>> >> >>At the telecon I was actioned to bring a new proposal on the reagle issues. >>This is a sketch intended to allow members of the WG who were absent at the >>telecon to comment. I will expand the details later (not on semantics - which >>I intend to leave to Pat's discretion) >> >>Changes: >> with comments >> c14n done in syntax doc >> implementation note added to concepts >> >>Syntax >>===== >> > > 7.2.17 http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/#start > > >>+ 7.2.17 changed to indicate that exc-canonicaliztion with comments and with >>empty InclusiveNamespaces PrefixList. is performed. (I think this was clear enough - proposed text is needed) >>+ add new link from part where it is said that use of N-Triples is not >>required to implementation note in concepts >> > > I don't understand this. Link from this section? To the > IMPLEMENTATION NOTE you propose below. > > There is a bullet point in section 6 > http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/#start Clarification: in section 6 http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/#section-Data-Model replace: [[This specification does not require that N-Triples be used to represent an RDF Graph.]] by [[ This specification permits any <a href="rdf-concepts#implementation-note">representation</a> of an RDF Graph (see [RDF Concepts]); in particular, it does not require the use of N-Triples. ]] > > Could you add some URLs to what you want to change? > Hope the above is clearer. > > >>Concepts >>======= >> > > In http://www.w3.org/TR/2003/WD-rdf-concepts-20030123/#section-XMLLiteral > > >>+ change lexical space of rdf:XMLLiteral to be strings that are root element >>content of canonical XML documents >> > > how about: > strings that are the contents of the root element of canonical XML documents > I was thinking along the lines of first defining value space and the mapping and then [[ The lexical space is the set of (string value) pairs that map into the value space. ]] It's sort of cheating. > >>+ change mapping of rdf:XMLLiteral to be a string concatenation >>'<rdf-wrapper xml:lang="' >>lang >>'">' >>string >>'</rdf-wrapper>' >> > > I should note that I've answered several people who wanted to know > where the rdf-wrapper element was defined, so maybe a more prominent > stating that this is arbitrary might help. Any suggestions as to how - it currently comes right after the first occurrences. I guess I could change the value space bullet point from [[ Have root element tag: <rdf-wrapper> ]] to [[ Have the fixed but arbitrary root element: <rdf-wrapper> ]] (One of the xmlschema editorial comments (2.5 in msg 0489) is to delete "tag") > > >>+ add implementation note at end of abstract syntax section >> >>IMPLEMENTATION NOTE: >>This section describes an *abstract* syntax which describes >>equality of literals and equivalence of graphs. This is the >>syntax over which the foraml semantics are defined. >>Implementations are free to represent literals and RDF graphs in >>any other equivalent form. As a first example: language tags may be >>represented in their original case, and language tag comparison would >>then be a case insensitive string comparison. As a second example: >>literals with datatype rdf:XMLLiterals can be represented in a non-canonical >> > > <tt>rdf:XMLLiteral</tt>s I assume > Yes. > >>format, and canonicalization performed during the comparison between two >>such literals. In both of these examples, the comparisons may be >>being performed either between syntactic structures or >>between their denotations in the domain of discourse. >>Implementations that do not require such comparisons can >>hence be optimized. >> > > This note reminds me, do we canonicalize the language strings to > lower/uppercase? I know it has been suggested (from I18N WG?) that > it is best to preserve this for people but given there is no other > variation allowed in literal or URI canoncalization, I think we > should consider picking one and requiring it. > Yes; we chose lowercase, mainly to make life easier for Pat. Tex Texin misunderstood that so the note is intended to clarify ... http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0460.html > >>Semantics >>======== >>+ follow concepts as appropriate >> (Note: there is still rdf:XMLLiteral as a special case because even though >>the mapping is simplified, it is still there, and it still requires the lang >>tag as an argument). >> >> >> >>******************** >> >>The first example with language tag case is intended to: >>- be easy to understand >>- partially address an issue raised by Tex Texin (possibly on behalf of I18N >>WG), no ID yet. >> > > Pointer to email? http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0460.html > > >>The second example is intended to address part of my action. >> > > Where are these first & second examples? > [[ Above, repeat: As a first example: language tags may be represented in their original case, and language tag comparison would then be a case insensitive string comparison. As a second example: literals with datatype rdf:XMLLiterals can be represented in a non-canonical format, and canonicalization performed during the comparison between two such literals. ]] > >>******************** >> >>The suggested wording for the lexical and value spaces of rdf:XMLLiteral in >>concepts permits the following: >> >><rdf-wrapper xml:lang=""> >> <eg:a xmlns:eg="eg:a" xmlns:unused="eg:b"></eg:a> >></rdf-wrapper> >> >>This does not correspond to any RDF/XML document. >>A more complicated wording: >>[[ >>CURRENT: >>The value space >> is the set of all XML documents that: >> >>+ Have root element tag: <rdf-wrapper> >> > > This is the point that has confused some people, looking for a > definition of rdf-wrapper. > > >>+ Have no attributes on the root element other than xml:lang >>+ are Canonical XML [XML-C14N] (with comments). >> >>ADD: >>**** >>+ which are unchanged when transformed using the exclusive canonicalization >>with comments and with empty namespace prefix list >>**** >>OR >>****** >>+ which have no namespace declarations that are not visibly used [EXC-C14N] >>****** >>]] >>could avoid this. >> > > The latter seems clearer, rather than defining the condition in terms > of yet another transformation. Yes, I'll go with that I think. > > >>(The example document would have the declaration for xmlns:unused deleted by >>such a transform, and hence be excluded from the datatype). >>Is that better or worse? >> > > If you mean the three line <rdf-wrapper> above, then I'm not sure > what to answer. If we are going for a tighter definition of what is > canonical, then some XML will be transformed to canonical form, so I > can't really say better or worse. The group(s) that created these > canonicalization transformations surely considered this. > > Dave > The editorial problem is that the inclusive C14N spec defines the term "canonical XML" which is actually quite useful in defining the value space. There is no equivalent term in EXC-C14N. The document: <rdf-wrapper xml:lang=""> <eg:a xmlns:eg="eg:a" xmlns:unused="eg:b"></eg:a> </rdf-wrapper> is canonical XML, but not in the corresponding set for exc-c14n. Choices are: - use term from inclusive C14N, and modify it (illustrated by my text) - use only terminology from exc-c14n and construct the concept we really want. Hope this is a bit clearer ... Jeremy
Received on Wednesday, 12 March 2003 06:34:18 UTC