Proposal: response.xml()

[fflorent]

Since XMLHttpRequest.prototype.responseXML used to exist, I guess response.xml() should exist too, right?

Florent

[domenic]

See the Note

Formats you would not want a network layer to be dependent upon, such as HTML, will likely not be exposed here. Rather, an HTML parser API might accept a stream in due course.

A network layer should not be dependent on an XML parser.

[domenic]

Sorry, didn't mean to close, that should be @annevk's prerogative.

[fflorent]

I am not sure what this note means. As I understand, a HTML Parser could build a DOM Tree as it receives data from the request, and the intermediate state of this tree exposed to the user? (sorry if I am completely misunderstanding)

Also I don't see why exactly for XML this proposal is invalid. An XML document meaningful (and valid) once it is entirely loaded, right? And why is this valid for JSON and not for XML?

Florent

[annevk]

JSON is low on complexity and JavaScript has JSON built-in.

[fflorent]

I thought it would have targeted browser environments (so parsers are built in them).

Edit: If you could explain a bit further (with links maybe) so I can be more pertinent next time I propose something else, I would be thankful.

Florent

[annevk]

The idea is to have some amount of layering in APIs. Say you implement fetch() in JavaScript. You would not want to import an entire XML and HTML stack to do that.

[fflorent]

Oh, I see now. Thanks for this explanation.

Florent

[Mouvedia]

@annevk so the reason for the lack of .document() (or .xml()) is the polyfill itself?
Well you don't have to worry since you have "document" listed here. And as you can see here it has been supported for quite some time now.
cf JakeChampion/fetch#204

Id say this should be reopened.

[annevk]

@Mouvedia no, the reason for lack of that is that it would be poor architecture. It would be better to have a way to create a document from a stream and use that.

[Mouvedia]

@annevk are you saying it belongs on whatwg/streams?