RE: i18n reviews of DOM 3 Core and Load&Save

On Tue, 2003-09-23 at 16:17, Francois Yergeau wrote:
> > normalize() is a DOM Level 1 method. The name is unfortunate since it
> > collides character normalization but we cannot change its semantics or
> > rename it. This explains the introduction of normalizeDocument(),
> > instead of reusing normalize() on Document nodes. An other example of
> > discrepancy with names is our namespaceURI and the [namespace name]
> > Infoset property.
> 
> This doesn't seem to address the comment.  Backward compatibility is
> certainly an issue, but not necessarily a show-stopper: there are numerous
> instances of "Modified in DOM Level 3" in the spec.  We did offer some ideas
> for addressing compatibility, they may be dead-on-arrival but we would like
> to understand why.

After reconsideration, we decide to follow the recommendation and make
the behavior change on normalize():
[[
If the parameter "normalize-characters" of the DOMConfiguration object
attached to the Node.ownerDocument is true, this method will also fully
normalize the characters of the Text nodes.
]]

> > > Also, it should be specified that this method is sensitive 
> > to the value of
> > > the "cdata-sections" config parameter.
> > 
> > Only normalizeDocument is sensitive to the configuration parameters.
> 
> Good to know, thanks.

Note that now, Node.normalize() is also sensitive to the parameter
"normalize-characters".

> > As an update, the following text was added on the description of the
> > DOMString type:
> > [[
> > If the normalization happened at load time, or the method
> > Document.normalizeDocument() was invoked (in both cases, the parameter
> > "normalize-characters" needs to be true), characters are
> > fully-normalized according to the rules defined in [CharModel]
> > supplemented by the definitions of relevant constructs from 
> > Section 2.13
> > of [XML 1.1]. Note that, with the exception of
> > Document.normalizeDocument(), manipulating characters using 
> > DOM methods
> > does not guarantee to preserve a fully-normalized text.
> > ]]
> 
> Good enough.  English is a bit poor perhaps, one wonders what is *the*
> normalization, some rewording would be appreciated.

Changed as follow:
[[
Characters are fully-normalized according to the rules defined in
[CharModel] supplemented by the definitions of relevant constructs from
Section 2.13 of [XML 1.1] if: 

      * the parameter "normalize-characters" was set to true while
        loading the document or the document was certified as defined in
        [XML 1.1]; 
      * the parameter "normalize-characters" was st to true while using
        the method Document.normalizeDocument(), or while using the
        method Node.normalize(); 
Note that, with the exceptions of Document.normalizeDocument() and
Node.normalize(), manipulating characters using DOM methods does not
guarantee to preserve a fully-normalized text. 
]]

> > > C8) DOMConfiguration interface, 
> > "check-character-normalization" parameter:
> > > it is not clear *when* this setting has any effect (i.e. 
> > what methods of
> > > what interfaces it affects).
> > 
> > [there is a pending action item on the Core editors to 
> > clarify that only
> > normalizeDocument is affected by the DOMConfiguration parameters]
> 
> ...unless specified elsewhere, as in Load&Save!

correct, as specified in the text above.

> > >  Since Charmodel says that text SHOULD be
> > > checked, the default for this should be true, the user 
> > having the chance to
> > > set it to false after careful consideration of the consequences (see
> > > definition of SHOULD in RFC2119).
> > 
> > The parameter check-character-normalization is optional so the default
> > cannot be true. Applications can certainly check if the parameter is
> > activated, or can be activated, using the methods defined on the
> > DOMConfiguration object.
> 
> The optional character of check-character-normalization is the first wrong
> (the other being that "true" is not the default).  As argued in our comment,
> a DOM user cannot do the right thing (check normalization unless careful
> consideration of the consequences...) if the normalization checking
> functionality is absent.  The DOM is missing functionality essential for
> things as ssimple and basic as string matching.  We object to that.

We rediscussed this issue again and didn't change our mind. An
invitation to join our teleconference next week has been sent to the
I18N Chair. I18N WG members are welcome to discuss this issue during the
upcoming teleconference.

Philippe