Binding Data Islands [Archive] - International Web Developers Network

View Full Version : Binding Data Islands

Pauly

June 29th, 2006, 15:29

I'm just playing about to see if I can do certain things, and ran into a problem.

I'm trying to bind my Data Island to HTML. I'm pretty sure it's me doing something wrong, because my browser doesn't show a parsing error, but it doesn't render the content either.

My Data:
<?xml version="1.0" encoding="utf-8"?>
<about_pauly>
<attr_title>Full Name</attr_title>
<attr>Paul Brendan Riddick</attr>
</about_pauly>

Trying to bind it:
<xml id="about_me" src="about.xml"></xml>
<dl datasrc="#about_me">
<dt datafld="attr_title"></dt>
<dd datafld="attr"></dd>
</dl>

I also tried using <span datafld="attr"></span> too, incase the DT and DD didn't like it, but it doesn't render that way either. I'm probably missing something simple yet crucial. Or do browsers not 'understand' this yet? I tried in both Opera, Fx and gave it a long shot in IE without serving it as application/xhtml+xml, all gave the same result - Nothing!

Pauly

June 29th, 2006, 16:51

<xml> is an unofficial tag, is there a way to bind data officially?

sea otter

June 29th, 2006, 17:55

PHP :)

BigBison

June 30th, 2006, 13:18

I'm trying to bind my Data Island to HTML. I'm pretty sure it's me doing something wrong, because my browser doesn't show a parsing error, but it doesn't render the content either.

My Data:
<?xml version="1.0" encoding="utf-8"?>
<about_pauly>
<attr_title>Full Name</attr_title>
<attr>Paul Brendan Riddick</attr>
</about_pauly>

That's a well-formed snippet of XML. So an XML parser won't have a problem with it. This, on the other hand:

Trying to bind it:
<xml id="about_me" src="about.xml"></xml>
<dl datasrc="#about_me">
<dt datafld="attr_title"></dt>
<dd datafld="attr"></dd>
</dl>

Is not XML, if you're viewing that with a desktop browser it would display in "quirks mode", the XML parser doesn't give you an error because it isn't being used.

Remember, a desktop web browser relies on the Content-Type HTTP header to tell it what XML is. Unless the Content-Type of the first snippet is 'application/xml' or 'application/xhtml+xml' (regardless of the document's actual format) it isn't using the XML parser either.

Opening an XML file from disk, using a web browser, defaults to displaying the file as text/plain not application/xml. If you're working with XML you need some tool other than a web browser to tell you what's well-formed, like an XML-aware editor.

A well-formed snippet of XML has (amongst other requirements) an XML prolog, and must be a "container". Your first snippet qualifies. The second snippet is not well-formed because it lacks a prolog, and because its root element is <xml> yet there's a <dl> outside that container.

Or do browsers not 'understand' this yet?

Just what are you expecting your browser to do with that code? If your goal is to serve it as HTML or XHTML and have it rendered in standards mode with either the browser's HTML renderer or its XML parser, then your document should be valid (X)HTML. Desktop browsers aren't expected to understand anything but valid (X)HTML markup, so that's all you should be feeding them.

You've lost me with the attributes you're assigning in your <dl>, I don't understand the purpose, and I don't understand what you're trying to render with a bunch of empty tags. Where's the content? What would make sense to me is this:

<?xml version='1.0' encoding='utf-8'?>
<html xmlns='http://www.w3.org/1999/xhtml' xml:lang='en'>
<head>
<title>some title</title>
<link rel='stylesheet' type='text/css' charset='utf-8' media='screen' href='style.css'/>
</head>
<body>
<dl title='about_pauly'>
<dt>Full Name</dt>
<dd>Paul Brendan Riddick</dd>
</dl>
</body>
</html>

That is a straightforward transformation which may be done using XSLT. My code is well-formed XML but isn't valid, because it doesn't declare a DOCTYPE. It does, however, declare a well-known XML Namespace on its root element which many XML-aware clients will interpret to mean that the document is XHTML and will therefore expect a <head> and a <body> and the HTML 4.01 strict tagset.

Served as 'application/xml' or 'application/xhtml+xml' my code snippet will work just fine in a desktop browser's XML parser. Served as 'text/html' Mozilla will display it in standards mode despite the absence of a DOCTYPE, so will some versions of Opera and various other browsers, while the rest will use quirks mode. IE < 7 will definitely use quirks mode, because it only ever uses standards mode if the very first line in a document is a standards-mode DOCTYPE.

Pauly

June 30th, 2006, 16:49

Although I didn't follow this originally, this is what I was trying to do: http://www.devpapers.com/article/269 - To find out it's unofficial.

If you take my blank elements, and the external XML, it's 'supposed' to create more tags to fit the data. The document wouldn't render empty elements. Like I said above it's an unofficial tag, but I can see advantages of being able to do it like this.

I assume you mean I can do this with XSLT? I apologise if I'm not following properly :oops:

sea otter

June 30th, 2006, 17:41

From TFA:
Data binding is a process that allows an Internet user to manipulate Web-page elements using an Internet Explorer Web browser. (emphasis mine)

'nuff said.

And what happens when you need to fill in more than one entry?

There are plenty of easy, proven ways to do this server-side that have worked for years and years on all sorts of sites large and small. And yes, even xml/xslt is an option here too.

Pauly

June 30th, 2006, 19:53

Moved to programming.

I guess the XML/XSLT way is what interests me, I don't suppose you know of any online examples, or tutorials I can follow/mess around with?

Pauly

June 30th, 2006, 22:01

Ok, I managed to transform my XML to HTML using XSLT, including DOCTYPE. Having my .xml output HTML but ...

... What if I wanted to remove the DOCTYPE etc? How would I go about including this .xml file into my (X)HTML document?

Or is there a more efficient way to do it?

sea otter

June 30th, 2006, 23:01

... What if I wanted to remove the DOCTYPE etc? How would I go about including this .xml file into my (X)HTML document?

Or is there a more efficient way to do it?

Errr....the whole point of xlst is to transform the xml into something else (in this case, xhtml). What would be the point of simply "including" the xml in a xhtml document?

Remind me why would you want to remove the doctype?

(I'm probably not understanding something here)

Pauly

June 30th, 2006, 23:13

I'm just experimenting so some of what I want to do, may not be possible, or even considered 'proper'. Nor am I bothered about compatibility at this stage, if I can see it on my desktop browser (Opera or Fx) - As long as it's standard.

What I was trying to do, was 'bind' XML data to HTML elements, and have them render within a .html document. The way I was seeing it, was I could stop myself using full (extensive) lists, and just use a 'simple set', something like;

<dl>
<xsl:for-each select="about_pauly/att">
<dt><xsl:value-of select="attr_title"/></dt>
<dd><xsl:value-of select="attr"/></dd>
</xsl:for-each>
</dl>

To truely seperate style and structure from data. I could then use the same data in other documents and style them completely differently, even using different tags, for example:

<xsl:for-each select="about_pauly/att">
<h3><xsl:value-of select="attr_title"/></h3>
<p><xsl:value-of select="attr"/></p>
</xsl:for-each>

I'm still putting pieces of the "puzzle" together, and still don't "get XML". I just want to play around with certain things.

sea otter

June 30th, 2006, 23:21

ah, ok got it.

xml/xslt is perfect for that. But what I'm guessing you're not "getting" is that something still has to happen on the server.

Key point: This is NOT DONE CLIENT-SIDE, which I suspect(?) is what you're after.

Basically, you need servers-side programs to process xml and xslt as input, and then grind it all into xhtml sausage and serve it up.

Typically this is done with xalan/xerces in Java. PHP5 has much-improved xml processing now added (there are PEAR.php.net classes as well) and Perl has loads of CPAN libraries for this as well. And I'm sure there are ASP/.NET equivalents too.

So you certainly aren't limited by your choice of server language either.

Hope this helps?

Pauly

July 1st, 2006, 00:40

Right, I didn't even know there was an extra step, I thought I could go from XML+XSLT to XHTML, with some sort of "XML include".

I'll look into what you suggested, and see how far I get. Thanks :)

sea otter

July 1st, 2006, 01:00

Pauly, what's your preferred server-side language?

Pauly

July 1st, 2006, 01:05

My personal site is on a PHP server :)

sea otter

July 1st, 2006, 01:18

Ah, well, lots of ways you can do it then. Unfortunately very confusing. Regardless, you'll need to have *some* form of xsl support compiled in, depending on which of the three-or-so methods you plan to use.

I assume you're still on php 4?

Pauly

July 1st, 2006, 01:22

Yes, 4.4.2 ...

Also, if it's anything, I think I have Perl :lol: It says so in cPanel ...

sea otter

July 1st, 2006, 01:26

and.....what xsl stuff have you got compiled in? libxslt or sablot? You can tell from phpinfo() by looking at the "configure" section at the top of the page.

Pauly

July 1st, 2006, 01:31

Whoa, not sure, I assume you mean the Configure Command part?

'./configure' '--with-apxs=/usr/local/apache/bin/apxs' '--prefix=/usr/local' '--with-xml' '--with-mm' '--enable-bcmath' '--enable-calendar' '--with-curl' '--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--enable-exif' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-gettext' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-mcrypt' '--with-mhash' '--enable-magic-quotes' '--with-mm' '--with-mysqli' '--with-mysql=/usr' '--with-openssl' '--enable-discard-path' '--with-pear' '--enable-sockets' '--enable-track-vars' '--with-ttf' '--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-versioning' '--enable-wddx' '--with-xmlrpc' '--with-zip' '--with-zlib'

sea otter

July 1st, 2006, 01:57

--with-xml
--with-dom
--with-dom-xslt
--with-dom-exslt

You're fine :)

Here's the page in the docs about the domxml library (which also does xslt):

http://us3.php.net/manual/en/ref.domxml.php

There's enough stuff there to choke a horse, but don't be put off by it. There are only three xslt functions (they all start with domxslt, and indeed if you look at the docs for one of them (http://us3.php.net/manual/en/function.domxsltstylesheet-result-dump-mem.php) you'll see that it all boils down to:

<?php
$filename = "stylesheet.xsl";
$xmldoc = domxml_open_file("data.xml");
$xsldoc = domxml_xslt_stylesheet_file($filename);
$result = $xsldoc->process($xmldoc);
echo $xsldoc->result_dump_mem($result);
?>

Happy hunting :)

Pauly

July 1st, 2006, 02:00

Thanks :)

BigBison

July 1st, 2006, 08:17

I'm trying to bind my Data Island to HTML.

But this isn't a Data Island, a term which refers to data which can't be shared easily. Your source document is an XML file, which means it is highly portable since all that's required to share it is HTTP and it can be read by any XML parser. If that data were in a non-semantic comma-delimited format then it would qualify as a Data Island.

Transforming an XML file into an (X)HTML file is a job for XSLT or XQUERY. The fact that this transformation is easy to do is why we store data in XML files instead of Data Islands.

Key point: This is NOT DONE CLIENT-SIDE, which I suspect(?) is what you're after.

I disagree. The latest generation of web browsers support client-side XSLT. Yes, there are issues and quirks because it's all very new (or in IE's case, old and neglected) but the example given in this thread is well within the abilities of Opera 9, Safari 2, IE 6+ and Mozilla versions comparable to Firefox 1.5+, which gives XSLT as much "penetration" in desktop browsers as JavaScript or Flash 8+.

Whether this is a suitable solution for Pauly's needs, I can't say. But I do know a few people who argue that XSLT should be considered strictly a client-side technology, to which I respond by pointing to my project and its server-side XSLTC implementation, available for Java apps.

The folks at Apache have given the nod to XSLTC over Xerces for XSLT 2.0 support. I don't think there's a PHP alternative to XSLTC, "C" for "compiler" as it compiles and caches XSLT, similar to how most PHP accelerators work. Using compiled XSLT on the server side makes lots of sense, but...

It really depends on what the objective is, as well as the server environment. Where possible, implementing XSLT on the client is much easier than fiddling with PHP or Java. XSLT documents are themselves well-formed (and preferably valid) XML. Web servers are most efficient when they're serving static text files, particularly when those files can be cached.

So if your source document can be served using URI + HTTP, all it takes is adding an XML Processing Instruction to link to your XSLT file, just like it was a CSS file. The client browser will cache that XSLT code and use it to transform each document requested from the server which links to it, just like it was a CSS file.

The server is then serving static documents, not executing a transformation for each request, as those CPU cycles are offloaded to the client. Just use 'application/xml' for the XML and the XSLT files, and the browsers I mentioned will all handle the transformation provided it's straightforward.

Pauly

July 1st, 2006, 16:00

Thanks for clearing that up Eric - I'm still new to all this, so my terminology is pretty crap.

Alright, basically the above PHP is doing what I was doing in the first place. Only giving a 3rd file to mess around with. Trying to include more than 1 file, inserts multiple DTD's, which is understandable now that I think about it.

Eric, you talk about XSLT acting as a sort of stylesheet, which is fair enough, I have a pretty good grasp on what it does - But what I'm having trouble with is this; What if I wanted to access 2 XML files at the same time, within 1 document, 'styled' by the same XSLT file?

So for example, I could call index.xml, which would 'include' about_pauly.xml and contact_info.xml, as well as index.xsl. I know how to call the XSLT, what I'm having a hard time with is putting the XML into a common place but keeping it seperate.

I hope you follow :oops:

BigBison

July 2nd, 2006, 08:20

Eric, you talk about XSLT acting as a sort of stylesheet, which is fair enough, I have a pretty good grasp on what it does - But what I'm having trouble with is this; What if I wanted to access 2 XML files at the same time, within 1 document, 'styled' by the same XSLT file?

There are myriad possibilities. XSLT and CSS are attached using XML Processing Instructions (or the <link> tag in the XHTML namespace) in an XML file. That XML file can use XINCLUDE to include another XML file, the combined "infoset" is what the attached XSLT code will transform.

XINCLUDE support is sketchy on web browsers, though, so at this time it's best implemented on the server side as support for XINCLUDE has greatly improved over the past year in most every server-side code library, and XSLTC.

Another option, is to have the attached XSLT file open an external XML file for inclusion using XSLT's document() function. But Opera's implementation only supports local files not URIs at this time. Once this is fleshed out, it will likely be subject to the same XSS restrictions as XmlHttpRequest() meaning that you can open a remote document, but only from the same server where the other files were obtained.

One thing most every XSLT implementation does get right is the ability of one XSLT stylesheet to include other XSLT stylesheets, allowing some very flexible modular applications. Just like you can make a CSS stylesheet "driver" which just @import's the actual CSS code from external files.

So for example, I could call index.xml, which would 'include' about_pauly.xml and contact_info.xml, as well as index.xsl. I know how to call the XSLT, what I'm having a hard time with is putting the XML into a common place but keeping it seperate.

You're having a hard time shifting your paradigm. ;) We don't use XSLT to "include" XML, we use it to transform XML. XSLT works by reading an input "tree" and writing an output "tree". If we want to copy all or part of an XML document we copy it from the input tree to the output tree, we don't "include" it.

I'm using XSLT extensively with my IWDN redevelopment project. The beauty of XSLT is that it's both a client-side and a server-side technology. My application can be set to either parse the XML Processing Instructions and run the transformation on the server, or just serve the XML without parsing, in which case the transformation will be run on the client. The code is the same, the difference is in the server configuration.

So the application logic is the same either way. What you want to do is have the URIs people will access point to XML files, and have those files attach your XSLT template. Here's the file I'll be turning into XSLT:

http://canuck.bisonsystems.net/dev/iwdn2/template.html

The changes are tedious but straightforward, since most of this document won't be changed at all. XSLT stylesheets allow literal XHTML, just like PHP scripts. It's a bit tricky to get the DOCTYPE output, and the XML Processing Instructions, but the <head> and <body> won't look any different.

Except for one change. After the <h2>Content</h2>, we'll insert three lines of XSLT code referred to as an "identity template". All an identity template does, is copies the nodes from the input tree as nodes in the output tree without any transformation. Therefore, any XML document which attaches this XSLT template will find itself "included" verbatim after the <h2>Content</h2> tag.

For example, if the following document...

http://canuck.bisonsystems.net/dev/iwdn2/example.xml

...had an XML Processing Instruction linking to the template file above, the result would be this:

http://canuck.bisonsystems.net/dev/iwdn2/index2.html

You can't call that "XSLT Inclusion" because that implies that one XSLT file is including another XSLT file. It's a transformation because the source document isn't included in the template, it is copied in one node at a time from the innermost nested element to the outermost (container) element.

So for example, I could call index.xml, which would 'include' about_pauly.xml and contact_info.xml, as well as index.xsl. I know how to call the XSLT, what I'm having a hard time with is putting the XML into a common place but keeping it seperate.

Yes, you're on the right track. If you have two separate source documents, it would make sense to combine them on the server. I'm sure PHP will allow you to use XINCLUDE, in which case your file is index.php it just happens to output XML. A standard PHP include would also work, there's no rule which says your PHP output has to be HTML, or that you have to use XINCLUDE to combine XML files.

Regardless, what you are trying to create is an "XML Infoset" which combines about_pauly.xml and contact_info.xml into one well-formed XML document with an XML Processing Instruction which includes your template. Except your template won't use an "identity template" because you need to transform the markup, but that's what you do -- embed that transformation code in the template which resembles your final result.

Whether that transformation is performed by server or client is up to you, the XML and XSLT code aren't affected by this decision.

sea otter

July 3rd, 2006, 04:29

Key point: This is NOT DONE CLIENT-SIDE, which I suspect(?) is what you're after.

I disagree. The latest generation of web browsers support client-side XSLT. Yes, there are issues and quirks because it's all very new (or in IE's case, old and neglected) but the example given in this thread is well within the abilities of Opera 9, Safari 2, IE 6+ and Mozilla versions comparable to Firefox 1.5+, which gives XSLT as much "penetration" in desktop browsers as JavaScript or Flash 8+.

Yes, yes. Quite correct. I wanted to address what I thought was his "disconnect" first, and then follow up RE client side (actually, I was hoping you would because this is really your area of expertise, and indeed you did :) )

The folks at Apache have given the nod to XSLTC over Xerces for XSLT 2.0 support. I don't think there's a PHP alternative to XSLTC, "C" for "compiler"

oh, agreed as well. If it really does have to live on the server, I'd much rather see it compiled. But as you say...

It really depends on what the objective is, as well as the server environment. Where possible, implementing XSLT on the client is much easier than fiddling with PHP or Java. XSLT documents are themselves well-formed (and preferably valid) XML. Web servers are most efficient when they're serving static text files, particularly when those files can be cached.

I'm always happier having as much done as possible client side.

BigBison

July 3rd, 2006, 04:36

The other alternative for client-side XSLT is Google's AJAXSLT, which is a set of XSLT libraries for JavaScript:

http://goog-ajaxslt.sourceforge.net/