Re: The XMLHttpRequest Object comments

On 5/7/07, Anne van Kesteren <annevk@opera.com> 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 <innovimax@gmail.com>
> 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 €