Murray Altheim wrote:
> Insofar as any balanced-tag markup is XML, then okay. But that's all
> that's being stuck in an 'island', not a complete XML document, just
> a fragment of tagged content. It's great that they're able to glom on
> to the marketing of the term "XML" but it really is just the freedom
> to put *anything* into a proprietary-formatted HTML document.
> The <XML> element isn't supported anywhere but IE5, and it might as
> well have been called <PDQ> or <ABC>. It has little to do with XML.
As I said before, it is an extension to HTML, and as you say, it could
be <PDQ> or <ABC>. However, the idea is that you can manipulate that XML
document through the DOM, once the complete HTML has been received. If
you try to put aside your anti-Microsoft prejudices for a moment, and
have a think about general issues of fragment interchange, you will see
that embedding a complete XML document within another is a common
requirement. All that needs to happen is that you mark the boundary
where you are making the transition from the container to the contained.
Microsoft have chosen to use the tag <XML> to show where the containing
HTML document gives over to the contained XML document - and perhaps
they could have looked at the fragment interchange proposals - and to
make it easier to understand for the people who are most likely to use
it, they have called it data islands.
As I said in my previous post, I don't use the technique for various
reasons - but to imply 'it has little to do with XML' reflects a lack of
understanding of XML and some of the important issues that have to be
addressed when targeting different parts of a document at different
applications (I use the words 'document' and 'application' in the
specific sense used in XML 1.0, in relation to the parser).
> Mark Birbeck:
> In fact, Microsoft have not touched XML with their data island
> > technique, they have merely wrapped it in HTML. If they are
> guilty of
> > any propriety extensions it is to HTML in allowing XML to
> be inserted
> > into it.
> Well, there's nothing saying that IE5 is HTML 4.0-only, so they're not
> violating anything there. It's not HTML according to any
> existing spec,
> but browsers historically have accepted all manner of trashy markup.
That's more like it. Now try saying "Bill's alright really. After all,
look at all that money he gives to charity."
> It's only wrong insofar as the main point I keep reiterating:
> that anyone misled into thinking their documents will be portable
> beyond IE5 is sadly mistaken. And as the world moves farther and
> farther away from the two browser world (and this is inevitable,
> especially as linux grows by leaps and bounds and device browsers
> become more common), these proprietary documents become less and
> less 'browseable'. It's just important that authors know where the
> boundaries are.
But even that depends on how you implement it. Ideally you end up with
the HTML+data island via an XSL transformation of an XML document that
effectively leaves the core XML intact and wraps a load of HTML around
it. Most likely anyone who is seriously developing with XML has a range
of XSL transformations that they apply to the same XML document in order
to create different output for different devices. Any future browser
that can itself handle XML as IE5 can, will have some type of 'data
island' feature, so changing this stylesheet should be fairly easy.
> And yes, we have beaten this horse into the earth.
I think so, but the reason I replied once more is because there is an
issue here as to how we get to the Nirvana we all want, without going
through stages that are not 'standard'. Given that the next generation
of browsers will most likely be completely XML first (rather than HTML
first), and XHTML will be just one way of looking at that data, then
anyone who advises steering clear of XML data islands because they may
change, whilst imagining that everything else will nicely move along as
standards better cross their fingers and toes. (Or be a big company with
money to burn ...)