15119 - FEATURE: Implement script based mechanism for loading an XML document and manipulating it via DOM interfaces

Status: VERIFIED FIXED

(Core :: XML, enhancement, P3)

Description

[Nisheeth Ranjan]

I'm putting this RFE in the bug system to track a feature that seems an
important addition to our current XML functionality.

Here's the email from Steve Muench at Oracle who suggested this feature:

>Is there now (I have downloaded M8) an equivalent set of features in Mozilla
>accessibile from javascript that would let me:
>
>   (1) Construct an instance of an XML Document
>   (2) Load/parse an HTTP-based URL to a "source" of XML
>   (3) Walk the DOM tree in the browser?

CCing Vidur.

I'm currently scheduling this for post-beta work.  Will try to bring it in more
if time permits.

Comment 1

[Nisheeth Ranjan]

Adding Tim Bray's comments for future reference:

Subject: Re: mozilla finally
Date: Fri, 12 Nov 1999 18:42:34 -0800
From: Tim Bray <[e-mail]>
To: [e-mail]

At 02:22 PM 11/12/99 -0800, you wrote:
>a mechanism for loading XML data
>from a URL via script. Both Nisheeth and I would like to talk to you at some
>point about an optimal way to implement that. IE solves some of the problem
>with XML islands and, I believe, also includes a mechanism for directly
>invoking a parser. We'd like to see how we can expose this functionality in as
>standards compliant a way as possible.

Hmm... I don't know of a standard that applies in this case.  Dom level
27 is supposed to have this stuff, right?  In the interim, is the
MS way hopelessly botched?  If not, why not just copy it?  A nice
add-on would be to expose a SAX interface for those cases where
the XML might be real big and you don't want to blow your memory. -T.

Comment 2

[Taras Tielkes]

In addition to a URL, a string (Javascript String) as a valid XML source would
be convenient.

Comment 3

[Ian Graham]

TEST OF MOZILLA HANDLING OF EXISTING ISLANDS: SOME PROBLEMS

I fiddled about with the IE  XML islands approach in the current
MOzilla (M14) build, to see what effect islands in existing documents
would have on the Mozilla HTML parser and renderer. There are some 
potential problems, which I outline below. 

At present, the Mozilla HTML parser will process an XML 'island' 
elements (and content) as 'unknown' HTML, and converts the data 
into usable data in the HTML 'tree'. This is sort of like the
IE 5 island - the data is just in the wrong place.
 
Howeover, there is a problem with the  handling of existing
islands. This is because the HTML parser can't handle empty-element
tags in an island, which means that elements are not closed properly. 
This problem is illustrated by the file:

http://www.java.utoronto.ca/NS5-bugs/island-test.html
which uses the script at
http://www.java.utoronto.ca/NS5-bugs/tree-traverse.txt

to write out an HTML doc listing some info about the document's
tree structure -- note how wonky it is. THis will break _any_ DOM
script on the page, even if the script doesn't use the island data.

This also means that you can't reliably use CSS to 'hide' an island,
since the XML element may not be properly ended.

Obviously this is not a critical problem (well, I wasn't able to
crash M14 with my tests), but this is worth trying to fix, if this
issue is actually handled.

The only obvious solution I can see is to mimic the IE approach, by 
hard-wiring the <XML> ... </XML> element to a special handler that 
removes the content from the HTML parser,and either discards it or
redirects it to an XML parser.  

Comment 4

[Martijn Pieters]

This would make my life easier, so we are tracking it for Zope Studio.

Comment 5

[Johnny Stenback (:jst)]

Cc:ing myself and [e-mail]. I strongly feel that mozilla without the

ability to load external XML from JS considerably limits the functionality/

flexibility that mozilla can offer to content/application developers.



I think this is a really important feature.

Comment 6

[Taras Tielkes]

Let's take the discussion about what kind of XML functionality we want to the 
new newsgroup, news://netscape.public.mozilla.xml

That will be easier to read and will keep this rfe from being cluttered up.

Comment 7

[Nisheeth Ranjan]

Moving bugs out by one milestone...

Comment 8

[rickg]

non-essential for m16

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Many people (including but not limited to me :) ) thinks this is an important 
feature, and since M16 is supposed to be feature-compleate shouldn't this be 
M16?

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

*** Bug 35234 has been marked as a duplicate of this bug. ***

Comment 11

[Nisheeth Ranjan]

Bringing in to M16...

Comment 12

[Martijn Pieters]

*** Bug 35234 has been marked as a duplicate of this bug. ***

Comment 13

[Taras Tielkes]

It would be extremely useful (and future-proof) if the actual HTTP request 
could take the form of a GET *or* a POST request.

In a typical (XML-RPC and SOAP come to mind) case the request message will 
consist of XML as well. Since GET url strings have limited carrying capacity, 
POST is the only way to send XML documents/trees of medium (say 2K+) size.

If a possibility is provided to send string/XML using POST, there should be a 
method to add custom HTTP headers, for instance "HTTP_CONTENT_TYPE:text/xml". 
All the form clunk and "x-www-form-urlencoded" mess is not welcome...

Basically, I'd like this object/component to have the functionality of ie5's 
XmlHttpRequest. Of course you wouldn't *need* to pass anything, just an URL to 
load XML would be enough.

XmlHttpRequest methods&properties:

http://msdn.microsoft.com/xml/reference/scriptref/XMLHttpRequest_object.asp

Comment 14

[Nisheeth Ranjan]

The fix for this is checked in.  See my post titled "Support for loading an XML 
document from script" in netscape.public.mozilla.xml.

Comment 15

[Gervase Markham [:gerv] (not reading bugmail)]

*** Bug 31331 has been marked as a duplicate of this bug. ***

Comment 16

[Taras Tielkes]

I would like to ask for a synchronous loading function as well.

This makes sense in a lot of cases and should not be too hard to add.

Comment 17

[Chris Petersen]

Marking verified per last comments.