On 5/7/07, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
Your attention to detail is much appreciated!
I had to ! All the rest is ok :-) ! On Mon, 07 May 2007 17:05:59 +0200, Innovimax SARL <[EMAIL PROTECTED]>
wrote: > Implementations should support some version of XML. If they don't > support some version of XML responseXML must always be null. [XML] > [XMLNS] > ]] > > Does it mean a conformant implementation could support NO version of XML? Yes, in theory.
Isn't there any possibility to put it other way such that at least one version must be supported ?
The version implied by the text is the version of XML. So "1.0" and > "1.1". There must be a reference to XML 1.1 specification in that > respect Argh, really? Having two references for XML seems already too much to me :-) I think the current text and references are good. Apart from Opera I'm not sure any user agent actually supports XML 1.1 so normatively referencing it doesn't like a good idea to me. The language used in the specification is backed up by the references which say XML 1.0 and Namespaces for XML 1.0.
In that case, I don't understand why "version" is referenced, since only " 1.0" is used, but "1.1" is never referenced.
What is not clear is about support XML 1.0 or XML 1.0 with Namespaces > : what is the expected behavior if the filename send is > [[ > <?xml version="1.0"?> > <::/> > ]] > which is a valid XML 1.0 file but not a valid XML 1.0 with Namespaces ? > > Please clarify the behaviour regarding this This is clear in the specification. It requires files to be namespace well-formed.
I, indeed, find that through reading the rest of the spec. But since, it is almost repeated each time in the spec, why not putting it here ?
== 1.2.2. Terminology == > [[ > There is a case-insensitive match of strings a and b if after > lowercasing both strings (by mapping A-Z to a-z) they are identical. > ]] > > I would prefer to read > > [[ > There is a case-insensitive match of strings s1 and s2 if after > upercasing both strings (by mapping a-z to A-Z) they are identical. > ]] > s1 and s2 because there is less confusion with letter a and b > uppercasing because it is used latter in the spec for method Fair enough, done.
Just to be picky, the uppercasing instead of lowercasing has'nt been included
==References== > [[ > [RFC2617] > HTTP Authentication: Basic and Digest Access Authentication, ... > ]] > should be > [[ > [RFC2617] > HTTP Authentication: Basic and Digest Access Authentication, P. > Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. > Stewart, editors. IETF, > June 1999 > ]] Indeed! Fixed. > Warning for next step : Reference to "Window Object" and "Document > Object Model (DOM) Level 3 Events Specification" are Working Draft Well, I think we can go to Candidate Recommendation and sit there until everything reaches that level, much like SVG Tiny 1.2 did.
Yes no problem for CR, it was a very preemptive warning
==Typo== > s/reqeust/request/ > s/resonse/response/ Fixed!
-- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 8 72 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
