XML Convert... | The Coffeehouse

ManipUni
Proving QQ for 5 years!

When XML first hit the shelves I was skeptical (me, skeptical, I know... Shocking?) but I must admit I've really been sold on the concept and it really works extremely well day to day. When I first looked at XML my thought was simply that you could accomplish the same thing using an *.ini format with simple '\n' and '=' delimiters. But since then and with me and parsers having something between small and large fallouts I have learned to love it.

I just love that someone else can send me XML and I will guess most of what they're trying to do including relationships. *.ini just cannot do relationships. If you have one layer of XML below a single root node then the merits are debatable but as soon as you add additional tiers and children it gets powerful, and you more often than not wind up doing that.

Now the thing I hate most is what I like to call "XML abuse." I think my biggest pet peeve is "ordered XML." Why in the heck would the order of nodes within the same scope matter? Isn't that just anti-XML? Couldn't you accomplish the same with child nodes?

XSL is "ok." But the template system still confuses the heck out of me. I understand what they are trying to do with it but frankly if they re-designed it so X-Paths had to be explicity defined (I know, an XML sin) I might be happier. Plus as a programmer I miss the power of a real language. The variable system is "ok."

I really want to do stuff like - foreach(node) select(number * multiplier) instead of having to create variables that contain the multiplication already. Just messy. Plus finding errors and creating these things is hell even in Visual Studio which helps a lot.

XML Schemas (XSD) are the WORST THING IN THE HISTORY OF THE WORLD. I'm sorry but not fit for purpose doesn't even begin to discribe how terrible these things are. The damn language doesn't even understand XML for a start... Memo to creators: Redudant nodes in XML does not break stuff. Ordered XML is moronic. And most people want to do a positive match not a negative matching -
e.g.
This - "Does this XML support all the nodes *I* support?"
NOT this -"Does this XML *only* support what I support and nothing more, in exactly the same node order for no obvious reason?"

Just terrible. Worst still if you think that this is their second attempt at creating a Schema language.

stevo_
Human after all

Never really hated xml, the more I've used it and the more I've needed forms of text serialized data, the more I really appreciate its design.

When the world first saw xaml, I saw an array of people saying.. ugh, xml? is this the best you could come up with.. and almost like microsoft felt they had to deny liking the format because it was xml, they said something along the lines of 'it was a quick fix, we're looking into something better'.

But I believe eventually said.. 'yep, we had a look and couldn't find anything that really enabled the declarative requirements whilst being more succinct'.

The first time I really started to play with xaml, I was really pleased with how clever a system it was.. I've ended up somewhat of a xaml fan.

Sven Groot
My name has 9 letters. Coincidence? I think not...

Now explain to me how I would serialize an ordered collection of objects to an XML file if I can't say that the order of the nodes is important?

With XHTML, would it be ok if the browser just randomly reordered the content of your document because it decided the order of the elements wasn't important?

sysrpl

I tend to build apps where XML drives my entire UI., and I've been doing it that way for a while.

One Example:

I wrote a remote image manager which syncs images from my computer to various web stores. I persist that image list as XML to an app local data folder on the user's hard drive. In the application UI I owner draw the photos with photo statistics in a custom scrollable windows class.

Using XML to hold the data is great, and I can easily use XPATH and XLST to create new sorted and filtered views. There is no need to deploy database or anything else. I rely on MSXML and my statically linked windows libraries. I deploy a single 200KB exe, set my server info, click sync, and I'm all setup on a new PC.

So yes, I agree XML is a great thing.

Btw: I wrote an XSLT editor application which makes developing, managing, and testing XSLT + <msxsl:script> simple. XSLT works a lot better if you can invoke a javascript function inside of an XPATH query.

ManipUni
Proving QQ for 5 years!

In reply to Sven Groot

#Oct 16th @ 8:53 PM

....

LeoDavidson

XML schemas make me laugh because they're so hard to define that there's more likely to be a bug in the schema definition than in the content it's trying to validate.

I guess they are useful for testing compliance against big, well-known XML standards where an expert has written the schema. Even so, for that it be easier to write a piece of code which validated the data.

Sven Groot
My name has 9 letters. Coincidence? I think not...

In reply to ManipUni

#Oct 17th @ 12:49 AM

So in XHTML you'd have to explitly number each and every element to preserve the order? Yikes.

ManipUni
Proving QQ for 5 years!

In reply to Sven Groot

#Oct 17th @ 1:44 AM

XHTML as far as I'm aware doesn't use ordered XML.

And:

Have the same meaning. The data within the nodes is ordered but we're talking about XML, not the data contained within it.

Sven Groot
My name has 9 letters. Coincidence? I think not...

In reply to ManipUni

#Oct 17th @ 2:28 AM

Untrue, the DTD for HTML (and not just XHTML, HTML 4 too) requires that body comes after head. This ordered thing isn't something unique to XSD, it's an inherent part of XML and indeed even SGML. A browser might allow you to swap head and body (never tried it, so not sure), but it certainly won't validate against the official DTD.

EDIT: And I was more referring to if you have a sequence of three <p> elements, you probably meant for them to be displayed in that order (barring CSS doing wonky things with them).

Bas
It finds lightbulbs.

In reply to Sven Groot

#Oct 16th @ 8:53 PM

Why didn't people ever wonder how to serialize an ordered collection of objects to a relational database, when those first appeared?

Sven Groot
My name has 9 letters. Coincidence? I think not...

In reply to Bas

#Oct 17th @ 2:43 AM

Ok, ok, I admit defeat on this point. But the HTML argument still stands.

EDIT: I guess I just don't see why it's a bad thing that XML allows you to use the implicit order of the elements in the document. It's not as if you're required to do so. It's easy to create an XSD (or DTD) that allows you to use the elements in any order.

Dexter

In reply to Bas

#Oct 17th @ 2:43 AM

How do you know that nobody wondered about that? Relational databases are based on set theory and sets by definition are unordered. XML is a markup language and that concept is usually associated with text documents. Text documents tend to have some order, you don't place the title of a chapter after the chapter's content for example.

And anyway, XML itself doesn't require/specify any ordering. The ordering is up to the specific XML language you're using:

- .NET's XmlSerializer doesn't care about the property order but it does care about the order of array elements.

- In XHTML the order matters in general. It matters in the sense that the flow order (and some other "orderings" like z-index and tabindex) is given by the element order. But there's no requirement to place all <p>s before all <input type="button">s in a <form>.

- XAML is a hybrid between the previous too (for example the property element syntax allows any ordering of elements).

ManipUni
Proving QQ for 5 years!

But that is just my point, XML Schemas only work well with ordered XML. If you want unordered XML with only positive matching instead of negative matching, well, frankly you just cannot.

e.g.
Let's say I want to match this format:
<Root>
<MyNode>
<Mydata>data</myData>
<MyOtherData>data</myOtherdata>
</MyNode>
</Root>

However I am happy to allow any order of XML nodes in the MyNode scope and for any third party nodes to be introduced (extensions). So for example this might be legal:

<Root>
<superNewFeature>
<Stuff />
</superNewFeature>
<MyNode>
<MyOtherData>data</myOtherdata>
<NewStuff>data</NewStuff>
<Mydata>data</myData>
</MyNode>
</Root>

And the Schema would match. But, nope, doing things like this is just impossible with XML Schemas as they exist today.

This sounds like a silly complaint but it actually makes embedding, and XML wrappers entirely unsupported.

What I want to do is write formats that are all positive matching then strip away the outter format (based on information contained within it) to expose an inner format.

Here is a bad example:
<?xml version="1.0" encoding="UTF-8"?>
<MyXHTMLWrapper>
<Format>XHTML</Format>
<DateTime>11:54 18/10/2009</DateTime>
<DateTimeFormat>hh:mm dd/mm/yyyy</DateTimeFormat>
<Message>
   <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <head>
           <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
           <title> Hello World Example </title>
       </head>
       <Body>Hello World</Body>
   </html>
</Message>
</MyXHTMLWrapper>

Matching this is exceedingly difficult with Schemas. Matching it is yet even more difficult still as it gets more complex.

Bas
It finds lightbulbs.

In reply to Sven Groot

#Oct 17th @ 2:45 AM

It's not meant as a point of defeat, I'm genuinely wondering. Why are we using the order of XML elements, but not the order of records in a database? Why the difference?

exoteric
I : Next<I>

I think the biggest irony of XML is that it's an extensible and human-readably language, or metalanguage if you will, and therefore, to avoid unreadable path notation, the whole extensibility is sacrificed in the name of micro-formats like XPath.

In a way XML should probably have been a double-effort between an extensible binary language (like EXI) and tools that provide domain-editing support for things like XPath without sacrificing their extensibility. That would also allow one to completely disregard attributes. And probably comments and processing instructions, CDATA sections, etc. Still, XML has been a God-send and we should all thank James Clark et al on a daily basis but microformats are a misunderstanding. Maybe a binary Lisp.

It's like structured editors were a bad thing, even if only provided very basic structure: we all need to be able to read everything in notepad. I think this is a huge mistake. It has meant XML was human readable from the outside, but is at odds with its own design goals.

Now as for W3C XML Schema, well it just isn't very nice to work with. But you get used to it. It's probably influenced by the shape-mismatch situation, what LINQ was designed to address.

exoteric
I : Next<I>

In reply to ManipUni

#Oct 17th @ 12:49 AM

Recursion is order!

AndyC

In reply to Bas

#Oct 17th @ 5:17 AM

Because sometimes it's convenient to describe things by putting them in-order. Relational databases can't do that, short of tagging rows with a numeric identifier for order which has it's own set of problems. This is one of the reasons that relational databases aren't a good fit for all solutions.

ManipUni
Proving QQ for 5 years!

In reply to AndyC

#Oct 17th @ 8:04 AM

Since and order is just a numbered list, I would argue that this makes relational databases and correctly used XML perfectly suitable.

AndyC

In reply to ManipUni

#Oct 17th @ 8:16 AM

But imagine:

<list>

.....

</list>

Then think what happens if you want to insert an item between "2" and "3". You have to go modify the attributes of each and every element from "3" onwards, even though nothing has conceptually changed about any of those elements. You're also making an items position in the list an attribute of the item, when it's really an attribute of the list. Of course you could then go on to solve that by doing creating a child element to add seperation, but then you start down a road of rather inefficient bloat.

Sometimes the best way to represent an order is just to present things in that order.

ManipUni
Proving QQ for 5 years!

In reply to AndyC

#Oct 17th @ 8:42 AM

I take your point.

But I would raise two things:

1) A third party cannot assert that order is important from viewing the XML

2) A third party will need to write "special code" to handled ordered elements

As I said I take your point in that example, but in general I don't think ordered nodes is very "XML."

PS - I think another good example of this situation is XML that defines how to handle large data blocks with the large data block at the bottom of the XML. If you don't read it in order you will have to read in the entire large block of data before you know what to do with it so might wind up doubling your effort.

Dexter

In reply to ManipUni

#Oct 17th @ 9:01 AM

1) A third party should know that from some sort of specification, not by looking directly at the XML.

2) My I ask what kind of "special code" are you talking about?! My experience leans towards the opposite.

ManipUni
Proving QQ for 5 years!

In reply to Dexter

#Oct 17th @ 9:14 AM

XML doesn't always come with a spec'.

Ordered XML implicitly has an additional value that others nodes lack, the position. You also need to handle cases like this:

<Root>

</Root>

How do you handle this? Does the "SomethingElse" change the context? Do you have three ordered nodes here or four? Is it 1-3, and 1, or 1-4? Or just 1-3?

Sven Groot
My name has 9 letters. Coincidence? I think not...

In reply to ManipUni

#Oct 17th @ 4:00 AM

If you want unordered XML with only positive matching instead of negative matching, well, frankly you just cannot.

Hmm, I thought this was possible but it appears you are right and it's not, because <xs:any /> is not allowed in <xs:all />. Weird.

Dexter

In reply to ManipUni

#Oct 17th @ 9:23 AM

Ordered XML implicitly has an additional value that others nodes lack, the position

Where exactly does the XML specification talk about "Ordered XML" or "position value"? I'm not aware of such things.

If I understand correctly your point is that the XML spec should have explicitly stated that the element order doesn't matter. OK, but that would be a very tough requirement to impose. Why? Let's try some XHTML:

<body>Isn't <b position="2">XHTML</b><i position="1">unordered</i> nice to read?</body>

I doubt that you or anyone else would like to see that.

Unordered XML might solve your problems but it would create other bigger problems. XML can't possible enforce the order of elements (or the lack of it) because that would be terrible limiting for various XML based languages that are out there.

ManipUni
Proving QQ for 5 years!

In reply to Dexter

#Oct 17th @ 11:25 AM

XHTML is a bad example since it isn't really legal XML anyway. The content within the nodes seems to be a mixed of other nodes and junk data that cannot be parsed using most XML parsers. I'm really far more interested in XML for data transit and messages.

Plus if you followed this thread, I was more upset about the XML Schema language's use for XML Ordering than I was about the XML abuse that happens because idiots want to re-create text based formats by adding < > around a few of the data points.

You can argue that there are valid uses for positional XML and I already admitted to one example and named a second within which order was important, but you also have to admit that for every correct use of ordered XML there are at least a dozen bad abuses of it.