Quick Lowdown on XML

It''s a way of representing structured data in a standard way.

You have elements, which represent objects, which are embedded within other elements. Each of these elements can have any number of attributes.

So, to represent my wardrobe, I could have

<wardrobe>
<shirts>
<shirt colour="red"> </shirt>
<shirt colour="blue"> </shirt>
</shirts>
<jackets>
<jacket colour="red" material="wool"> </jacket>
<jacket colour="blue" material="stainless steel"> </jacket>
</jackets>
</wardrobe>


Im sure you have an impressive wardrobe, unfortunately i cannot see any of it!

Perhaps Im suffering from a case of 'The Emporers new clothes' syndrom and should just shut my mouth, smile and nod.



Edit: Ahh! There she be.

[edited by - AndreTheGiant on February 16, 2003 9:50:43 PM]

Thanks BB,
although from the XML code that Ive seen, your example would have looked more like this:




sure its a lot longer then what you wrote, but its exactly the same information (unless i made a typo), and its much easier to write a parser for.

This is the kind of thing Im wondering though. There is really no standard way to Write XML is there? Like I know the tags have to match up and must be properly nested, but thats about it right? you can use any name and organize it any way you like right?
Im still confused about how there are courses about XML when it can be very clearly explained in about 5 minutes. I must be missing something big, but i dont know what!




[edited by - AndreTheGiant on February 16, 2003 10:31:10 PM]

[edited by - AndreTheGiant on February 16, 2003 10:31:45 PM]

What does XML do?

Your example is another way of representing the same data.

If you're implementing a full XML parser, you're going to have to read attributes as well. Attributes assign attributes to elements, just like in HTML.

Also, this is valid XML:

<element attribute=""/>
(which is equivilant to
<element attribute="">. </element> )

That's just about all there is to know about XML. There are other technologies based on XML which are more complicated, but the whole point of XML is that it's simple.

[edited by - benjamin bunny on February 16, 2003 10:49:59 PM]

What's sad is that LISP had this capability about forty years ago, plus LISP contains the ability to parse itself easily, and is more flexible.

Ever look at nested LISP lists containing symbols? Hello? Congratulations to XML. Someone reinvented the wheel with less functionality thirty years or forty years later.

LISP is a languge in which it naturally operates and processes data of a format that can be molded to the same semantic meaning of XML. The original CYC knowledgebase, essentially a semantic network based on frames, is similar to XML, and was implemented in LISP.

[edited by - bishop_pass on February 17, 2003 3:43:02 PM]

XML: Not impressed.

I wrote an article about this, which I sent in about 6 months ago.

As far as I know, the staff still have it.

This is, I think, the third time I''ve seen a topic asking for exactly what my article covers.

Excuse me while I shoot myself now.

*shoots self*

In my opinion:

There''s more here than you guys realise. Yes, xml is extensible markup, yes it has attributes etc. Yes you could have written an XML document shortly after computers developed file input & output. Most financial and industry systems still exchange data in EDI which is position delimited. But that''s not the point.

The real power of XML, what makes it SO useful, is that it''s supported by EVERYTHING.

Oracle, Sybase, Interwoven, Vignette, SQL Server, PHP, dotNET, Websphere, Weblogic, EJBs, J2EE, internet explorer. MSMQ, MQseries, JMS, the list goes on and on.

Everything can be serialized as XML.
Everything can be de-serialized from XML into whatever you want, objects, data, you name it.

It''s an endlessly flexible tool that all other tools support, without having to do much at all.

It can be transformed easily through XSLT.
Industry specific vocabularies can be developed to replace EDI, make messaging more robust. Documents can be well formed and validated against DTDs, data integrity is preserved, even if partially received.

SOAP, UDDI, web services, all XML based.

There''s SO much to XML, and yet on the surface so little that I can see how you might think it''s the Emperors'' new clothes but trust me, there''s a reason why entire communities are devoted to XML development.

-ww

@ WillyWag, man its really kind of funny. the only thing i ever see you get mad/excited about seems to be DB related. lol

you love data base systems bro, and the XML that initializes it. hehe

quote:

---

Original post by WillyWag
The real power of XML, what makes it SO useful, is that it's supported by EVERYTHING.

---

One of the great fallacies is that because something is popular it *must* be good.

quote:

---

Oracle, Sybase, Interwoven, Vignette, SQL Server, PHP, dotNET, Websphere, Weblogic, EJBs, J2EE, internet explorer. MSMQ, MQseries, JMS, the list goes on and on.

---

XML offers consolation to those who insist on technologies with crippled data processing capabilities. Such as those which mung object representations so much in the compilation process that there is no hope of actually reconstituting a representation format of an object for sending down a wire. Have you actually read about the efforts Stroustrup is having to go to in order to rectify the problems with C++'s removal of type information?

quote:

---

Everything can be serialized as XML.
Everything can be de-serialized from XML into whatever you want, objects, data, you name it.

---

Everything can be serialised as XML as long as you invent an XML schema which defines certain tags and imbues them with the semantics that mirror the required semantics that they have whilst they live at a particular network node (such as an application). Then, of course, you still have to have the right parsers for the schemas that you (or someone else) invent. This sort of replication is a direct result of having a data representation format which can only be apart from the actual representation format. In effect, it is reintroduction of meta-information to technologies which, through the wild pursuit of efficiency, decide to strip out lots of useful information.

For instance...


Imagine that tag enters an application. What are the semantics? Is it a string, an integer or what? Perhaps we can do this:


OK, so now when we parse the document we see the attribute tag and we know to parse it as an int. So, we use the host language's coercion facilities to turn it into an int. What about when it's shared across two systems which have different coercion facilities? How about this:


What about a floating point number? How can we be sure that a calculation using the element value will be the same on both systems? Well, we could impose a format for the interchange of tags, such as an IEEE representation for floats. But what happens when the host language doesn't adhere to the IEEE standard? So then we have to write our own IEEE Abstract Data Types, and use them in place of native types.

That's just the start of the process. The next thing we realise we want to do is perform document transforms, and decide it would be beneficial to express them in XML itself. Then we realise we want to perform RPC calls between processes, and decide to express them in XML too. Then we want more sophisticated manipulation of the internal XML tree, so we invent XML-based scripting languages. On and on goes the horror of the W3C efforts. Why is the entire world engaging in a massive operation to make XML do all this stuff when we've had the technology readily available since long before XML was invented? What is so wrong with our wider community that we either don't realise these things exist, or that we decide to cook up half-baked reinventions anyway? How long do you think it will be before XML can do what Lisp has done for the last 20 or so years? Why have we taken a huge detour lasting several years just to be approaching a Lisp with bad syntax?

quote:

---

It's an endlessly flexible tool that all other tools support, without having to do much at all.

---

It's not "endlessly flexible". You are spouting rhetoric. It is fairly obvious that everything has it's limits and cannot be "endless".

quote:

---

It can be transformed easily through XSLT.

---

That's misleading. The ease with which it can be transformed is obviously a function of both how complicated the transform is and how well XSLT can express the transform. It can be transformed easily if the transform isn't too hard, or if XSLT is suited to the particular characteristics of the transform.

quote:

---

Industry specific vocabularies can be developed to replace EDI, make messaging more robust. Documents can be well formed and validated against DTDs, data integrity is preserved, even if partially received.

---

Document validation and integrity checking are the absolute basics of any data interchange format. It is disingenuous to claim them as particular benefits of XML. Every single important system I've worked on which hasn't been XML-aware, even the most idiotic developers have been able to realise files have to have trailers. As for validation, every application will validate the document either implicitly or explicitly. The benefit of explicit pre-validation comes in when you have long running batch processes where an invalid document causes significant processing delays, and costs CPU.

quote:

---

There's SO much to XML, and yet on the surface so little that I can see how you might think it's the Emperors' new clothes but trust me, there's a reason why entire communities are devoted to XML development.

---

XML is the Emperor's New Clothes because it doesn't give us anything we didn't have before. The only benefit is, as you point out, the ubiquity of XML. With XML reinventing the world in it's own image, it is hard to avoid. But that doesn't mean it is the *right* solution to all our data problems.

quote:

---

Original post by AndreTheGiant
I cant understand why my school has entire courses on XML, when Ive just explained the whole thing in 1 or 2 paragraphs.

---

Because they are not always teaching stuff specific to XML, but because they are having to teach data modelling to an entire generation who never realised the importance of being able to structure data. I've worked at organisations where they run large mainframe systems, and have worked alongside mainframe "oldies". Those people have far superior data modelling capabilities to the recent generations of script kiddies. I'm not sure why this knowledge has disappeared over the last few years. I'd conjecture that, while techniques such as OO, Design Patterns and the like have given something to the community, they have also taken a lot away. What they've taken away seems to be the ability to reason about data and structure of data. Perhaps if industry valued developer education over Silver Bullets, hype and jumping on bandwagons, then we wouldn't be ending up with problems requiring solutions on a scale mankind has never seen before. Maybe it is all about the data, after all...

[edited by - SabreMan on February 18, 2003 6:13:16 AM]

Wow, you sure have a lot of pent up emotion over three little letters.

Well, I can''t say I disagree with you entirely but I can say that I don''t Agree with you much either since I don''t really understand the point of your post. The general theme to it seems to be anger over XML.

Personally, I think it''s great. 99 out of 100 other folks do to. That''s about all I can tell you.


rock on brother.
-ww

quote:

---

Original post by WillyWag
Wow, you sure have a lot of pent up emotion over three little letters.

---

Not really. My post is just trying to give a sense of the enormity of the mistakes we keep making. I''ve become far too accustomed to such mistakes to really become emotional about them.

quote:

---

Well, I can''t say I disagree with you entirely but I can say that I don''t Agree with you much either since I don''t really understand the point of your post.

---

The point is this...

quote:

---

Personally, I think it''s great. 99 out of 100 other folks do to.

---

...people that think it is great are usually unaware that there have been superior alternatives for many years. My point is to publicise that fact. If you realise that a superior alternative existed at the very same time that XML was being conceived, you come to realise that there''s something very wrong with the IT community. If there''s a moral, then it should be that we take the time to educate ourselves about these things. Software has only had a short history, so how is it that we collectively forget so much useful work, and end up reinventing over and over again (and often come up with inferior solutions)? I''d contend that the missing sense of history is what most holds us back in going forward.

What do you do when someone mentions a technology you are unfamiliar with? Do you humour them and ultimately ignore what they''ve said, or do you become curious and find out for yourself what that person is talking about?

quote:

---

The general theme to it seems to be anger over XML.

---

No, I''m not angry. Maybe a little frustrated, but definitely not angry.

Well, ok, I''m starting to see your point. I was probably a little harsh regarding the anger and all. I see now you''re frustrated and that''s ok.

I tend to have a different viewpoint. Lisp was great for lists. Lex was great for token parsing. YACC was great too.

XML is just the next iteration on these technologies. I reckon content validation through DTDs and extensible tags through attributes are a big improvment over LISP lists. Perhaps it a case of 2 steps forward, one step back? I dunno.

Personally, I''ve come to expect this from the industry. I reckon it''s evolution. My expectation is that the technology takes a few tries to get things right, that''s why I''m not an early adopter. XML has been around many years now, it''s not going anywhere. I haven''t seen LISP in a while and frankly if I proposed using LISP for a b2b, I''d be laughed at. NOT because it''s no good or necessarily a bad technology, but it''s simply not as prevalent as XML.

Whether or not that''s good or bad I dunno. I''m not out to change the world. I just want a quiet life where I get to do things I find interesting with a computer and hopefully make some money at the same time

peace,
-ww


P.S. This is the FIRST conversation I''ve had with anyone on this board that I haven''t been insulted on. Thanks for that.

quote:

---

Original post by WillyWag
I tend to have a different viewpoint. Lisp was great for lists.[...]

---

Well, that is part of the problem. Many people hear the name "Lisp" and it conjures up "List processing" or "Artificial Intelligence", but Lisp is about so much more than those things. It might have been about List Processing in 1958, but it''s come a long way since, and can turn all the same tricks that any respectable modern language can, and then some. It''s a serious general-purpose tool. It was the first OO language to get an ISO Standard for starters, and I''m convinced that it''s also got the best OO system out there.

quote:

---

XML is just the next iteration on these technologies. I reckon content validation through DTDs and extensible tags through attributes are a big improvment over LISP lists. Perhaps it a case of 2 steps forward, one step back? I dunno.

---

More like just one step back.

quote:

---

Personally, I''ve come to expect this from the industry. I reckon it''s evolution.

---

Absolutely, but one has to wonder why evolution sometimes rejects superior designs. In software terms, it''s not always about the technology. Politics, sociology and circumstance all play their part. I''m not really sure why Lisp isn''t more popular, all I know is that it should be.

quote:

---

My expectation is that the technology takes a few tries to get things right, that''s why I''m not an early adopter. XML has been around many years now, it''s not going anywhere. I haven''t seen LISP in a while[...]

---

There are actually some excellent implementations of Lisp around - serious commercial implementations, that is. Lisp is there if you look, and people are using it for commercial software.

quote:

---

[...]and frankly if I proposed using LISP for a b2b, I''d be laughed at.

---

That''s understandable, but it''s an attitude that shouldn''t be put up with. How many of those people who would laugh at you actually know anything about Lisp? By that, I mean beyond the dubious single paragraph descriptions to be found everywhere around the web. Once you start to look into the case for Lisp, it is so overwhelmingly strong that it has to be taken seriously by any reasonable person. For example, check out Paul Graham''s Beating the Averages article.

quote:

---

NOT because it''s no good or necessarily a bad technology, but it''s simply not as prevalent as XML.

---

Well hopefully Beating the Averages explains why popularity might not be the advantage you would think. And neither should popularity be self-perpetuating.

quote:

---

Whether or not that''s good or bad I dunno. I''m not out to change the world. I just want a quiet life where I get to do things I find interesting with a computer and hopefully make some money at the same time

---

Well, that''s what I believe to be the *really* strong point of Lisp. Like you, I''m interested in programming and I like playing around with various languages and technologies to see what they can do. This is where Lisp scores: once you get past the initial "oddness" coming from a language like C++, Lisp is fun! It''s the most fun I''ve had with programming in a long time. Python is kinda fun too, but it lacks some features I consider important for large-scale development. And why shouldn''t developers want to develop in something that is fun? I can probably outcode myself 2:1 or more if I''m having a fun day, so it''s in the best interests of everyone concerned that I have fun.

XML, as with any technology is what you make of it.

As for Lisp parsing itself: write this file:

(car ''(((a))(b c d e)))
 

and save it as ''car.faz.gaz.bar''

Now, have it parse itself--really, parse itself... or did you use something like CLisp?

-=-

As for Lisp offering suppior abilities, well I cannot really argue there--however XML is more used to design how data is presented, and Lisp is designed as a ''LISt Processor.''

And yes I agree, that if a community has lost the ability to understand how data structure works--well.. we might as well all be contagious with C Programmer''s Disease.

quote:

---

Original post by DakeDesu
Now, have it parse itself--really, parse itself... or did you use something like CLisp?

---

I''m afraid I''m not seeing what point you are trying to make. You seem to be obliquely referring to the fact that Lisp programs are represented as Lisp lists, but that''s as far as I get. What does CLisp have to do with your point?

quote:

---

As for Lisp offering suppior abilities, well I cannot really argue there--however XML is more used to design how data is presented, and Lisp is designed as a ''LISt Processor.''

---

Lisp is designed as both a means of representing data and code. The idea that it is just for processing lists is out of date by about 40 years.

quote:

---

Original post by bishop_pass
What''s sad is that LISP had this capability about forty years ago, plus LISP contains the ability to parse itself easily, and is more flexible.

---

With that car.baz.gaz.bar (whatever), I was disputing this point.

quote:

---

SabreMan
Lisp is designed as both a means of representing data and code. The idea that it is just for processing lists is out of date by about 40 years.

---

You are right--it is only natural for the language to evolve over that period of time.

XML, in design was meant to have its manhood chopped off--it even says so on W3C''s specs (under the guise of using SGML''s most used features, and leaving the rest behind).

quote:

---

Original post by DakeDesu
With that car.baz.gaz.bar (whatever), I was disputing this point.

---

I''m still not getting your point.

quote:

---

XML, in design was meant to have its manhood chopped off--it even says so on W3C''s specs (under the guise of using SGML''s most used features, and leaving the rest behind).

---

We''re making a comparison between XML and Lisp, not XML and SGML. The reason stuff was left out of SGML is that it was quite a heavyweight specification for marking up documents, as opposed to just data. From the data representation point of view, the things that were left out are supposed to be irrelevant.