W3C home > Mailing lists > Public > www-tag@w3.org > January 2013

Re: Highlighting issue of XML support in DOM 4

From: Daniel Glazman <daniel@glazman.org>
Date: Tue, 22 Jan 2013 15:32:51 +0100
Message-ID: <50FEA313.9030402@glazman.org>
To: Henri Sivonen <hsivonen@iki.fi>
CC: Noah Mendelsohn <nrm@arcanedomain.com>, "www-tag@w3.org" <www-tag@w3.org>, Norm Walsh <ndw@nwalsh.com>
On 22/01/13 15:22, Henri Sivonen wrote:

> I think the TAG should not push for change in this case. The XML
> declaration is not part of the logical content of the document. It is
> a serialization artifact. After the parsing phase, applications should
> not alter their treatment of an XML document based on what was in the
> XML declaration. In that sense, the stuff from the XML declaration
> does not belong in the data model.

Oh come on... The XML declaration belongs to the
document instances and there should not be represented in the OM?
Wherever you put it, on the Document or elsewhere,
the XML declaration is still not only useful but mandatory for other
dialects of XHTML and for other XML-based languages. It's not
a "serialization artifact" only.

> round tripping for other reasons. For example, the DOM doesn't store
> information about white space between attributes, whitespace around
> the equals sign in attribute syntax or whether single or double quotes
> were used around the attribute value. For better or worse, BlueGriffon
> is a DOM-based editor, so it won't be able to round-trip source text.
> I think we shouldn't add/keep warts in the DOM to allow slightly more
> source round tripping in BlueGriffon when it's clear that the DOM
> isn't going to support full source round tripping anyway.

I totally disagree. And there is quite a BIG difference between the
unsignificant whitespaces you're quoting and the XML declaration...

Whatever you think, the fact we have in our XML document instances a
significant (ie not collapsible) construct that our OM cannot reach
even read-only is a hole in our architecture.

Received on Tuesday, 22 January 2013 14:33:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:51 UTC