Re: Re: XML, what is that supposed to do?

> First when most people say "the internet" now, they pretty much mean > "the web" and e-mail. When people say "the web" they mean HTTP and HTML > (with a little SSL thrown in for e-commerce). HTTP is the transport protocol > (how it is delivered) and HTML is the markup language (the message). XML > attempts to replace and supersede HTML without saying anything about HTTP > (though one can assume that most of the delivery will be done via HTTP, much > to the chagrin of many security administrators who depend on firewalls). That is not really the case. XML cannot be a replacement for html because xml is not a set of defined elements like html is. Think of XML as the _rules_ for defining your own markup languages. XHTML is an attempt to being html in-line with the XML standard, but there are gazillions of XML DTDs (document type definition, basically says what elements and attributes you can have in a particular XML document) for all kinds of things. XML is fantastic specifically because it is _not_ a markup language: it enables companies and industries to create _their_own_ markup languages for specific purposes. > XML is a markup language like HTML. Unlike HTML, the markup language is > extensible (basically think of it as saying you can define your own tags and > attributes). This means you can make descriptive tags such as Ah, from the above, I thought you did not understand, but you do :) > <book type="paperback"><AUTHOR>Joe Blogs</AUTHOR><TITLE>SATs > - How to be > beaten by the system</TITLE><SUBJECT>Test preparation</SUBJECT></book> > > Which looks a lot like HTML but isn't. Interestingly, the tags are > descriptive of the content which beats the hell out of UN/EDIFACT if you've > ever had to do any work for big business. Other differences are the rules > are more rigid than HTML: all tags must close, all attributes must be > quoted, all reserved characters must be escaped properly, all tags and > attributes are case sensitive. The default format for display is double byte > encoded characters (UTF-16 / UNICODE) (Note: The default used by PHP seems > to be UTF-8 so you should change it to that charset in the XML directives > line).- > So basically what you have when you are done is a text based > hierarchical data structure that's extensible and machine readable. That's > all XML is. yeppers. I luv xml. :) > Now the things you can do with it. Obviously for one I can use this to > serialize objects in PHP very easily since I can store objects in XML > representation which is just a string to be saved. The WDDX module does that > in some standard way. yes, and you can use it for document storage, remote procedure calls, EDI, _anything_ that has a data payload :)! > A note about standards. Since XML is extensible, there is a need to be > specified so that I can communicate with you and we understand each other. > XML is really more like a markup language FORMAT than a language (or seen > another way, it's a standard but not a specification). There are various > specifications and attempts at specifications out there and are usually > referred to as DTDs, Document Type Definitions, or Schema. It used to be you > specified your Schema in another markup language called SGML but then some > people figured if XML is so extensible you should be able to specify your > own Schema in an Schema language which itself is XML. This is known, not > surprisingly, as XML Schema. Which represents another thing you can do with > XML: Use XML to specify XML data formats. for example, a DTD for that bookmark example above is unly useful if a bunch of people agree on it as a standard, otherwise it doesn't do any real good. > A useful one for web programmers right now is you can use XML to turn > XML into other XML formats. This is done through XSL-T (eXtensible > Stylesheet Language - Transform) which is built into a PHP module called > Sablotron (Side Note: I couldn't compile Sablotron 0.50 in PHP yet, it yes, this is a slightly more sad situation. (feel free to flame away - but you have to do it on this list, not privately :) XST (and XSLT) are fairly good for transforming between two document types, but some people have started using it as a template mechanism for XML -> HTML. Problem is, you have to write like _ten_times_ as much XSL as html just to get a basic template going. XSL is like CFML but the design is even worse (gah) and it can't talk to a database :)! (ok, that't not a perfect example...) > failes during the linking step in Apache and claims that it can't find some > library that is in Expat). Sablotron (and many XML-T parsers) is a little > robust in that you can use it to transform it into HTML and text too. This > warrants a bit larger description... > > Basically XSL works by taking an input XML file (we'll call this the > "data store") and using another XML file written using the XSL specification > (we'll call this the "rules file") to create another file in a different XML > format (we'll all this the "presentation file"). Obviously when the > presentation file is in XML, we can chain another rules file to it to make > another presentation file and so on. XSLT parsers such as Sablotron allow us > to do just that. Why is this powerful? The best way is through examples > > (1) Our company builds a search engine that goes out and does a > real-time travel comparison engine of 25 separate travel websites. Given > that each search does this, we offload this to a business rules server that > creates this and returns the results. Because we add sites and features > almost at will, this messaging standard had to be extensible. The webserver > has to communicate with this business rules server and understand it. A > stylesheet can ensure that the message that gets sent to the web server is > always in line with what the webserver can understand even if we upgrade our > features on the business rules server. That is cool, but why XSLT? Why not a bit of php code that is comparably quite small? > (2) Furthermore, we have some nasty internal business rules embeded in > our XML data store on the business rules server. An XSLT filter allows us to > remove these internal business rules before delivery. This makes our > business objects resellable to third parties as an application service > without compromising our internal ones and requiring much coding. we can use > the same XML data store to store private and public information. I don't understand this, but that isn't surprising because there isn't enough context :) > (3) The webserver itself needs to parse and deliver the data. That data > may vary on our site vs. a cobranded site. With XSLT you can transform XML > on the fly to XHTML (a superset of HTML) and tack on your presentation layer > (nice little font tags and setting the color and whatnot). A different XSLT > for a different browser or cobrand, yet the same datastore for all of them. > This is called "separating your presentation from your data". Microsoft > calls this 3-tiering, n-tiering, DNA, NetDocs, and now dotNet. (Well some of > the later ones are a bit more than just 3-tiering, but the basic idea is in > tact). yes, this is a central argument I've had with a few people: using XML and parsing all that data coming out of a database is a huge hassle. XML should be an output format and a storage format, used somewhat similarly in a system as HTML. for example, if you're talking to a browser, spit out html. if you're talking to an XML-RPC server, spit out XML if you're talking to a cell phone, spit out WML, etc. I disagree with the idea that using schema-defined files as a base, paired with gobs and gobs of XSL is the groovy way to go. anyway. > Well I hope you get the idea. I'm sure you can thing of other things > such as... > > (4) Oracle, Microsoft and others now allow you to query their databases > in XML. So do companies (in my field) such as Apollo and Sabre. These are > hardly compatible, nor do they in any way represent something that is > comfortable to manipulate. An XSLT layer as a data abstraction layer allows > you to transform someone else's standard into an internal one you can > manipulate in a known way. aargh :) 10x the code, and it doesn't get you anything :) I heard about that oracle XML-query thing, gotta check it out... but I'm rather fond of SQL. > (5) I mentioned XML is machine readable. Imagine: web pages are not very > machine readable. Need I say more? yes, but only if the machine knows the rules of the document. that's been a problem, foofy non- or proprietary standard that no one bothers to document. :) > I could go on, but I'm not an imaginative fellow. seem pretty well informed to me :). > Let's see. There's also PDF. PDF isn't in XML but there is something > called XSL-FO (formatting objects) which some PDF generators (perhaps the > two that PHP has modules for?) understand. So writing XSL-FO for output for > a PDF generator is "doing XML" also. yeah, apparently this is a complete nightmare. (speaking as someone who has not actually done it, mind you :) > Then there is the fact that it hierarchical data which sometimes, > despite all these neat tools, needs to be parsed and understood. If we had a > standardized API for manipulating it, then all the knowledge in learning the > API for say visual basic on a Windows box can be transferred to doing in in > C++ in AIX or perhaps PHP? Yes, there are two such standards, one is an > event driven one (reads a tag and calls a callback function) known as "SAX" > (Simple API for XML) and implemented in the Expat (--with-xml in PHP which > is compiled by default in PHP4) and the other reads the whole thing into a > hierarchical (treelike) object structure called the DOM (Document Object > Model) which is implemented in libxml (--with-domxml or somesuch in PHP). read: SAX is fast as hell, and works really well for simple, not-very-nested xml documents. it is event based: Ohhhhh! A tag! I'll call a function now to handle the fact that I have encountered a tag! have a nice day! DOM is the serious, bad-ass big brother of SAX that reads the DTD associated with that document, and (usually) enforces all kinds of inconvenient rules about form and correctness :) - it then takes the _entire_ document, and turns it into a hierarchy (which is what an XML doc is). I like dom too, but it has problems right now. Also, most XML stuff I'm doing is _so_ simple (which is nice) that using SAX is all that's really necessary. once again, convenience reigns over correctness :) > I personally prefer the DOM version of looking at things (it's a bit > slower and chews more memory). Unfortunately the dom-xml in PHP doesn't much > resemble anyone elses DOM (at least not Oracle's or Microsofts), it's a bit > buggy (for instance, you can't remove a node, nor can you seem to modify the > text in a node) and it chews a whole slew of memory (much more than I'd > expect and that amount has almost doubled since they've incorporated XPath > support with PHP 4.0.4+). > > Now a final reason why PHP and XML should go hand in hand. (Because if > you haven't figured out by now, I'm really big on PHP and on XML). A study I > read estimates that by the end of this year over 50% of the Fortune 500 will > be using XML in some "test bed" situation and by 2004 80% of all business > communication on the internet will use XML. totally. virtually business communications at the machine level are being converted to XML. > I hope this gives you some motivation to pick up XML and use PHP to do > so. Because the more of us that are doing so, the more developers there will > be working (or pushing others to work) on improving XML support in PHP. With > more robust cool tools like the PHP developers have already given me (and > hopefully will continue to do so), I won't feel so bad about studying > condensed matter physics and neuroscience for the last 9 years instead of > majoring in something real like computer science and learning how to code in > Java and C++. nah, the former's more interesting anyway :) > Take care, > > terry chay _a (oh yes, the obligatory ad for binarycloud: go to http://www.binarycloud.com - it's a beefy web application platform in PHP!)