- From: Shane McCarron <shane@aptest.com>
- Date: Wed, 12 Sep 2007 06:18:59 -0500
- To: Mark Birbeck <mark.birbeck@formsPlayer.com>
- CC: Fabien Gandon <Fabien.Gandon@sophia.inria.fr>, "public-rdf-in-xhtml-tf.w3.org" <public-rdf-in-xhtml-tf@w3.org>
In XHTML xml:space is always set to preserve. See http://www.w3.org/TR/2006/WD-xhtml-modularization-20060705/conformance.html#s_conform_user_agent production 8 Mark Birbeck wrote: > Hi Fabien, > > I agree with you...at least I think I do, but I can't find any > suitable references! > > I'm almost certain that leading and trailing white space in element > content in XML is discarded, unless you set @xml:space="preserve". > Now, that does raise an interesting question which we haven't > considered before, which is whether the parser should honour the > setting of @xml:space. But putting that aside, I also can't see why > there is a trailing space on test 29. > > Perhaps Michael could help? Are you using a non-XML parser in your > tests, which might account for the fact that leading and trailing > spaces are not being dropped? Or am I wrong that they are supposed to > be dropped? > > Regards, > > Mark > > On 12/09/2007, Fabien Gandon <Fabien.Gandon@sophia.inria.fr> wrote: > >> Hello, >> >> TC29 is the only thing preventing me to release the new transform an >> parser and I think it is a pity. >> >> Can anyone explain me how the children nodes of the <span> in TC29 >> should be processed to pass the test ; in particular the text nodes. >> >> I currently have two options: >> >> 1 - I normalize-space() the values and obtain the wrong result: >> <rdf:Description rdf:about="http://example.org/foo"> >> <dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/" >> rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Mark >> Birbeck</dc:creator> >> </rdf:Description> >> >> 2 - I don't normalise-space () the values and obtain the wrong result: >> <rdf:Description rdf:about="http://example.org/foo"> >> <dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/" >> rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Mark Birbeck >> </dc:creator> >> </rdf:Description> >> >> I don't see the algorithm for generating the trailing white space of the >> current test (especially in XSLT1) and to me it is not clear how the >> process described in section 4.3 generates this trailing space. >> >> Moreover if I don't normalize-space() I no longer pass TC28 since in >> this test case the corresponding ASK does not have a trailing space even >> if the original RDFa does have spaces and break-rows in the <span> ... >> >> TC28: >> http://www.w3.org/2006/07/SWD/RDFa/testsuite/xhtml1-testcases/0028.sparql >> http://www.w3.org/2006/07/SWD/RDFa/testsuite/xhtml1-testcases/0028.xhtml >> >> TC29: >> http://www.w3.org/2006/07/SWD/RDFa/testsuite/xhtml1-testcases/0029.sparql >> http://www.w3.org/2006/07/SWD/RDFa/testsuite/xhtml1-testcases/0029.xhtml >> >> Failing a SPARQL query on a white space is pretty frustrating when one >> knows all the other things that could have gone wrong ;-) >> >> in one word: HELP ! >> >> in two words: HELP PLEASE! >> >> Cheers, >> >> >> >> Fabien Gandon : >> >>> Hello, >>> >>> I am passing all the tests except TC29 see discussion bellow. >>> In addition I would like to suggest 3 new TCs: >>> http://www-sop.inria.fr/edelweiss/people/Fabien.Gandon/docs/w3c/rdfa/tests/2007/09/10/ >>> >>> TC 46: multiple properties separated by white spaces >>> TC 47: multiple relations separated by white spaces >>> TC 48: a VEvent example using @instanceof >>> >>> >>> Hausenblas, Michael a écrit : >>> >>>> TC11: Hm. Not sure how I could help here, but let me know >>>> if I can do anything ... >>>> >>>> >>> We found the problem: instead of using a datatype I must use the old >>> RDF syntax rdf:parseType="Literal" >>> >>> >>>> TC29: The additional space is there on purpose; cf. also the review >>>> at [1] >>>> >>>> >>> When reading section 4.3 paragraph 2 : >>> "The [current object literal] will be set as a [typed literal] if the >>> datatype attribute is present, and does not have an empty value. The >>> actual literal is either the value of the content attribute (if >>> present) or a string created by concatenating the inner content of >>> each of the children in turn, of the [current element]. The final >>> string includes the datatype, as described here:???" >>> >>> I still don't see why and how I am supposed to generate this trailing >>> space ; could someone tell me what is the algorithm for going from the >>> concatenation of the XML nodes of the source document to the >>> xsd:string of the ASK? >>> >>> Cheers, >>> >>> -- >>> Fabien - http://ns.inria.fr/fabien.gandon/ >>> >> -- >> Fabien - http://ns.inria.fr/fabien.gandon/ >> >> >> > > > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
Received on Wednesday, 12 September 2007 11:19:28 UTC