Re: XML incremental rendering, was Re: Standards mode and Quirks mode (was Re: [CSS21] Test Suite)

> > Just only one: document cannot be rendered (drawn) until XML parser is
not
> > sure that the xml is well formed.
>
> Can you point at a spec that says that *anywhere*, even for fringe
> circumstances?

First:

2.1 Well-Formed XML Documents
[Definition: A textual object is a well-formed XML document if:]
1. Taken as a whole, it matches the production labeled document.
2. It meets all the well-formedness constraints given in this specification.
3. Each of the parsed entities which is referenced directly or indirectly
within the document is well-formed.

Taken from: http://www.w3.org/TR/2004/REC-xml-20040204/#sec-well-formed

Second:
4.1. Documents must be well-formed
Taken from: http://www.w3.org/TR/xhtml1/#h-4.1


> > How it supposed to look like actually?
>
> Specs could define what it is supposed to look like. Or they could be
> flexible and require that a) no further processing be performed and b)
> the user be informed of the error.

Right.

Until we have not such specs any attempt to render partial
content - (non-valid XHTML document) is a non-standard behavior.

XML specs (or XHTML) should have something like "well formed fragment"
definition and principles of its determining.

Otherwise it wouldn't be an XML popular by its strictness but something like
"Yet another HTML which looks like XML this time".

Andrew Fedoniouk.
http://terrainformatica.com



From: "Robin Berjon"
> Andrew Fedoniouk wrote:
> > From: "Robin Berjon":
> >>  .... * therefore, there is not a single argument against incremental
> >>    rendering of XML documents...
> >
> > Just only one: document cannot be rendered (drawn) until XML parser is
not
> > sure that the xml is well formed.
>
> Can you point at a spec that says that *anywhere*, even for fringe
> circumstances? If not, then you can have your opinion and I respect it,
> but you're not describing the behaviour of any conformant UA, and
> therefore I don't see what this discussion is about.
>
> > Illustration:
> >
> > Let's say we have a printer (as an output media) and  following xhtml:
> >
> > <html>
> > <body>
> > <p>paragraph</p>
> > </html>
> >
> > When UA (optimistic one) have got the </p> it starts rendering it -
draws
> > 'paragraph' on
> > physical paper page. Then after reading </html> it discovers that
document
> > is not well formed so it is not a xthml at all.
> > So UA should return paper page back to the printer tray and clear it
> > somehow? Not bad, eh?!
>
> No one ever said that. The document is in error and that should have an
> effect described by the relevant specification. One way in which it
> could be done would be by printing "Non-conformant document" in big type
> as soon as the error is encountered. If you feel that the relevant
> specifications aren't clear enough with respect to signaling error
> conditions on print media, then please take your comments to the
> appropriate WGs.
>
> > Even in case of screen media: document appears on screen and then it
will
> > dissolve somehow?
>
> Have you never seen something disappear from a computer screen? Have you
> never gotten an error message from your computer? If not, you're one
> lucky person.
>
> > How it supposed to look like actually?
>
> Specs could define what it is supposed to look like. Or they could be
> flexible and require that a) no further processing be performed and b)
> the user be informed of the error.
>
> > If UA will left partial content on
> > the screen then it means that UA uses input language other then XML.
>
> You can repeat that as many times as you like, it won't make it true.
>
> According to your description, if the UA displays an error message
> (partial content) then it's not XML-conformant. Just because it *reacts*
> to something that is no an XML document doesn't mean that it does not
> conform to XML -- quite the contrary in fact.
>
> > For any given  XML you cannot render/draw (change state of the view)
> > partialy.
> > Or forget about XML.
>
> Prove it.
>
> -- 
> Robin Berjon
>

Received on Tuesday, 27 July 2004 15:11:51 UTC