Re: Updated Editor's Draft of rdfa-syntax

Hi!

I agree with Ivan's concerns.

For my regular uses, I see no biggie in a default collapsing, my
preferred way being what Ivan outlined (which looks the same as the
definition of normalize-space() in XPath
(<http://www.w3.org/TR/xpath#function-normalize-space>). But in
general, not preserving space at all could be troublesome, possibly
for all kinds of literals -- I'm thinking of programming code snippets
for instance.

Still, I understand the potential issue with certain browsers (which I
assume also dictates the algorithm, perhaps making my wish for
normalize-space output moot). Though as Mark just replied, which ones
are they? I recall lots of DOM walking with droves of white space
textnodes to shuffle through.. ;)

But I wonder if RDFa should really "succumb" to them? Conformant XML
parsers are *required* to hand off text nodes to the application
untouched. In this case though -- parsing RDFa in the browser -- we're
constricted by already *being in the app*. And I see the problem of
e.g. saying "parsers *should if possible* leave white space intact",
since conformance would be really hard to measure (and would probably
be a poor ambiguity in a spec of this stature, since determinism would
be lost).. And we've "succumed" (IMHO correctly) to both no @xml:base
and no meta/link in body based on the XHTML application.

Because of that, relying on @xml:space here can't "save" us either,
right? It's not present in XHTML 1.1 (just as @xml:base isn't). So
even if it was added to the XHTML1.1+RDFa doctype, few to no browsers
would care at all.. For XHTML2 on the other hand, perhaps this would
be good? By comparison, SVG supports @xml:space.

My current point of view is that, ideally, @xml:space="preserve" would
work, and without it RDFa in XHTML would default to normalize-space,
having:

    <span rel="dc:creator" xml:lang="">
        Niklas
        Lindström
    </span>

yield:

    <> dc:creator "Niklas Lindström" .

Which is something I suspect casual users may expect anyway..(?) But
alas, if XHTML1.1+RDFa is supposed to work in existing browsers
(fairly reasonable :D), perhaps it must "succumb" to the less ideal
scenario. Stripping leading and trailing space could of course still
be expected, since that can be done after any default white space
collapsing. So I suggest at least that is left to be decided.

(A last, wicked thought: if the DOM does normalize space, *perhaps*
resorting to innerHTML would still provide the raw value (notably with
raw tags, entities and all)? Not exactly standard (until HTML5?), but
still.. ;])

Best regards,
Niklas



On 9/27/07, Mark Birbeck <mark.birbeck@formsplayer.com> wrote:
>
> Hi Ivan,
>
> That's right...or at least that's what we've been assuming in all of
> our discussions on this topic, but I'm not seeing that in the tests
> I'm running at the moment. It's possible that the behaviour we're
> concerned about is only seen when browsers like Firefox are running in
> XHTML-mode--all my current tests are in HTML-mode, which might explain
> why I'm not seeing the problem.
>
> I'll keep you posted. :)
>
> Regards,
>
> Mark
>
> On 27/09/2007, Ivan Herman <ivan@w3.org> wrote:
> > Sigh.:-( You mean: the DOM calls give you a normalized version of
> > strings instead of what comes through the wire? :-( :-(
> >
> > Is that actually conformant behaviour for a browser when implementing
> > the DOM? I wonder...
> >
> > Ivan
> >
> > Mark Birbeck wrote:
> > > Hi Ivan,
> > >
> > > But just to recap what the problem is, in some browsers we simply
> > > cannot get all of the data. So we had to make a decision as to whether
> > > to insist that all whitespace is preserved, thus condemning
> > > browser-based RDFa parsers to be non-conformant, or to define things
> > > based on the lowest common denominator--normalised whitespace. We
> > > chose the latter approach, and there is no way to axctually know what
> > > spaces were there in the first place...unfortunately.
> > >
> > > So unless someone can find a cunning way to get the original mark-up
> > > in browsers that normalise the whitespace, I think we're stuck.
> > >
> > > (I have to say though, just looking at this quickly I'm not seeing the
> > > removal of any whitespace in my tests...I'll look into this a bit
> > > more, but can anyone remember which browsers were giving us a
> > > problem?)
> > >
> > > Regards,
> > >
> > > Mark
> > >
> > > On 27/09/2007, Ivan Herman <ivan@w3.org> wrote:
> > >>
> > >> Ivan Herman wrote:
> > >>> _However_: I wonder whether this is the right thing to do for XML
> > >>> Literals. I still think that copying the XML literal verbatim might be
> > >>> the best option...
> > >>>
> > >> Just one argument that came to my mind: what should happen if
> > >>
> > >> - there is a <pre> portion in the HTML code
> > >> - it is put into the RDF graph as an XML Literal
> > >>
> > >> I am not sure it is kosher to re-format that portion... On the other
> > >> hand, I also do not think that RDFa processors should be asked to
> > >> 'parse' the XHTML portion to make this type of decision...
> > >>
> > >> Ivan
> > >>
> > >>
> > >>>>> And, of course, I am anxiously waiting for the
> > >>>>> @instanceof finalization, to get that done, too...:-)
> > >>>> working on it...
> > >>>>
> > >>> :-)
> > >>>
> > >>> I.
> > >>>
> > >>>> -Ben
> > >>>>
> > >>>>
> > >> --
> > >>
> > >> Ivan Herman, W3C Semantic Web Activity Lead
> > >> Home: http://www.w3.org/People/Ivan/
> > >> PGP Key: http://www.ivan-herman.net/pgpkey.html
> > >> FOAF: http://www.ivan-herman.net/foaf.rdf
> > >>
> > >>
> > >
> > >
> >
> > --
> >
> > Ivan Herman, W3C Semantic Web Activity Lead
> > Home: http://www.w3.org/People/Ivan/
> > PGP Key: http://www.ivan-herman.net/pgpkey.html
> > FOAF: http://www.ivan-herman.net/foaf.rdf
> >
> >
>
>
> --
>   Mark Birbeck, formsPlayer
>
>   mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
>   http://www.formsPlayer.com | http://internet-apps.blogspot.com
>
>   standards. innovation.
>
>

Received on Thursday, 27 September 2007 14:47:26 UTC