- From: Philippe Le Hegaret <plh@w3.org>
- Date: 10 Sep 2003 16:35:25 -0400
- To: Curt Arnold <carnold@houston.rr.com>
- Cc: Johnny Stenback <jst@netscape.com>, WWW DOM <www-dom@w3.org>
On Sat, 2003-08-30 at 13:09, Curt Arnold wrote: > I agree that with making xmlEncoding read-only. It should reflect the > encoding (if any) that was specified in the XML declaration when the > document was initially loaded. Subsequent changes to the document may > result in the document may not being able to be saved in the encoding, > but that is something to deal with in Load/Save. I assume that > actualEncoding and xmlEncoding would be null on a document created using > createDocument. Correct. It has been clarified that actualEncoding can be null as well, "such as when the Document was created in memory." > Was xmlStandalone also made read-only and strictly based on the value in > the XML declaration present when the document was loaded? Yes. > However, > there should be something in L/S that allows you to specify that you > want to document serialized with standalone="yes" which would either > place everything in the internal subset or expand entity references and > explicitly serialize default attribute values. > > I can see a case for making xmlVersion read/write, but it would be > better if it could be symmetric with xmlEncoding and xmlStandalone so > that it only reflects what version, if any, was stated in an XML > declaration. Having it read-write and influencing the allowable names, > is like having xmlEncoding read-write and throwing an exception if a > tagname was specified that could not be serialized in that encoding. We need to look at that from the LS perspective. Johnny? > Could not an XML 1.1 aware implementation accept legal 1.1 name at any > time, but an attempt to save a document containing XML 1.1 (only) names > as XML 1.0 would throw an exception? Correct. One can change the value of xmlVersion and then try to serialize the Document. I differ to Johnny to see if he wants to document that case in this well-formed fatal error case. imho, we shouldn't try too hard to document all those cases otherwise we'll end up having to define an XML catalog for error cases. Philippe
Received on Wednesday, 10 September 2003 16:36:46 UTC