RFE: XML Data Islands support




19 years ago
10 years ago


(Reporter: irichard, Assigned: nisheeth_mozilla)




Firefox Tracking Flags

(Not tracked)




19 years ago
Only an enhancement request

XML Data Islands are a Microsoft IE5 feature. I wouldn't expect you to provide
all MS extensions. However, this is a pretty useful one for thin clients which
use http to transfer data as XML. The crux of it is that we'd get a consistent
way to get at the XML embedded into documents.

This is a really exciting example of its use in IE5.


I presume you'll have no trouble finding details of MS's documented element.

Comment 1

19 years ago
Ian Richards, I believe this request is a duplicate of bug 15119, which has been 
marked fixed. Can you check if it is?
Summary: Enhancement Request: Can XML Data Islands be supported? → RFE: XML Data Islands support
It is :-)


*** This bug has been marked as a duplicate of 15119 ***
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 3

19 years ago
Marking verified then :-)

Comment 4

18 years ago
I re-open this bug because the requested functionality is in no way implemented 
at this time. The original enhancement request describes inline data islands.

http://bugzilla.mozilla.org/show_bug.cgi?id=15119 (fixed) describes out-of-band 
XML loading&parsing. This functionality is in Mozilla now, and working. (See 
the xml n.g. for details)

Data island functionality is related to 15119, but not the same thing. The 
request here is for an easy way to include XML fragments into (non-XHTML) HTML.

One possible approach is to just include custom XML into the HTML document and 
hide it using CSS. However, empty elements (<carrot/>) are not recognized by 
the HTML parser. This prevents correct DOM access to the embedded XML data.

The IE5 browser implements inline xml data islands using the <XML> tag.
One other valid syntax is, IIRC, <SCRIPT language="XML">

To summarize:
We need a cutom tag (or an extension of an existing (script?) tag that will 
have the following properties:
-all tags inside the delimiter tag are ignored by the HTML parser&rendering 
-the XML tree inside the delimiter tag is acessible as a XML Document interface
Resolution: DUPLICATE → ---


18 years ago
Ever confirmed: true

Comment 5

18 years ago
setting to New

Comment 6

18 years ago
I'm adding this copy of a posting to the xml n.g. to this bug. Some useful 

Here's the online MSDN documentation:

Microsoft syntax:

This gives a good overview: (W3C XML in HTML Meeting Report)

To summarize:
-inline xml data islands should always be enclosed in a specific tag
-a property ("XMLDocument") should be used to access the XML Document from the 
enclosing HTML level tag.


Comment 7

18 years ago
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future

Comment 8

18 years ago
I would like to add that both "inline" and "external" islands (as implemented 
in IE5) have their uses. A common pattern is to use two islands, one for xml 
data, and the other for XSL/XSLT.
adding helpwanted... (i'd sure find this feature helpful and useful!)
Keywords: helpwanted

Comment 10

18 years ago
A possible hack would be to reuse the SCRIPT element (that has CDATA contents) 
for XML, as described in http://www.w3.org/TR/NOTE-xh

At the moment, you can get the CDATA contents of SCRIPT elements through HTML 
DOM1. That character string can then be passed to the XML Parser component from 
the "xmlextras" module. Unfortunately, this workaround only works 
for "embedded/inline" script elements, since the "loadstate" and contents of 
SCRIPT SRC=... elements is not available through HTML DOM1.

If there is a lowel-level Mozilla interface to access the readystate/loadstate 
and CDATA contents of external SCRIPT elements, a small wrapper component could 
be written that takes an element ID of a SCRIPT element, checks if the element 
is loaded (when external/SRC=...), gets the CDATA string, parses it, and 
returns a XML DOM Document reference.

SCRIPT elements containing XML could be marked language="XML" or 
type="text/xml", as mentioned in the W3C DOM note.


18 years ago
QA Contact: chrisd → petersen
I know it's been over a year since anyone commented on this bug, but here's my
two cents:

There should be no need for an <xml>...</xml> tag.  There are a number of ways
we can import an XML document into an HTML document and its corresponding DOM. 
iframe elements and object elements are two of the ideas which come to mind. 
With iframes, it'd be window.frames[frameid].document.  With object elements,
it'd be document.getElementById(frameid).contentDocument.

Microsoft's support for the same is quite different -- they force a default
stylesheet on us when we don't use an XML data island.

In short, I don't see a reason to break HTML compliance for this, when current
HTML support -- and the current, good state of the Document Object Model -- will
be more than enough.  I recommend INVALID or WONTFIX for this bug.

Comment 12

17 years ago
I'm guessing that if this is ever implemented it would only work in quirks mode
as by including xml data islands it would render a page non w3c html4 compliant.
I'm also guessing that this is not exactly an xml feature but really a html feature.

Comment 13

17 years ago
See also bug 116277.
Because we have a bug to document a workaround for this, I'll mark this WONTFIX.
Please see bug 116277 for details about the workaround.

Last Resolved: 19 years ago17 years ago
Resolution: --- → WONTFIX


16 years ago
QA Contact: petersen → rakeshmishra
*** Bug 278501 has been marked as a duplicate of this bug. ***
*** Bug 305562 has been marked as a duplicate of this bug. ***

Comment 17

13 years ago
*** Bug 327577 has been marked as a duplicate of this bug. ***
*** Bug 327577 has been marked as a duplicate of this bug. ***

Comment 19

13 years ago
That is the different with Microsoft.
They most support Java...
Why? Java is common.
Over 70% user using IE in the world.
If user can't see content with other browser, what will they do?
Ans: use IE.
If technical support don't waste time to solve this. what will they do?
Ans: Add the sentence at bottom "Best viewed with IE ....."
Because they are the common browser.
Duplicate of this bug: 466615
You need to log in before you can comment on or make changes to this bug.