Project report

Document (globalcampus.site/namespace.stxt): Chapter 8: STxT and XML Default: Title: STXT: The Book Metadata: Title: Chapter 9: STxT and XML Description: We compare STxT with XML and show similarities and differences. Author: Joan Costa Mombiela last modif: 2013-03-01 Header: Warning to the Reader Content: This chapter may offend the sensitivities of enthusiastic XML readers. Read at your own risk ;-) Header: The Legend Content: The origin of evil: SGML. It all started a long, long time ago in a dark land called "informatics." Encodings roamed this world. Sowing incompatibilities. Hindering communications. Laughing at those who were not like them. Some tried to make peace with all of them. And then they created the monster: SGML. The monster began by stating which encoding it would stick with. And there was no problem. But the effort was too much. A bunch of strange characters were needed. Texts filled with "<", ">", "&xxx;". Unintelligible. And they have reproduced. The world is full of their offspring. Little monsters that fill the earth with these characters, hindering reading for humans. Only a handful of elites can deal with the monsters. They are called "The IT People." They are the terror. Nobody wants to see them, but everyone needs them. They are dark. They speak strange tongues. But the monsters are still here. They have mutated. Now they are called XMLs. And people like them!! ... But a small group of people gathered and decided this couldn’t go on. They would create a champion. Someone to enlighten them. There could be only one. Alert: The time for @STxT@ had arrived. Header: The Present Content: The world is full of ugly documents, _XMLs that we like..._ even though it's a horrible format! We are inheriting an outdated format, with outdated encodings, with a very IT-centric mindset. And it's everywhere. And we keep using it. And we want it for everything... Wait a minute! Stop! Is it necessary? If we knew nothing about SGML and wanted to have a quick-to-parse TXT, with structure, with namespaces, would we have created XML? I don't think so. If you asked a child to invent something, I suppose they would never have created XML... they would have made something more natural... THEY WOULD HAVE CREATED @STxT@! Well, we have more experience, and we’ve learned. Let's create it! Header: First Contact Content: I don't want to scare you, but @STxT@, compared to XML, is: * Prettier * Simpler * More compact * Faster And it can also express the same things. Let's take a look at an XML example, and we’ll compare it with @STxT@ to start. It’ll be an easy example: Code: John Smith Mery Adams Keyla Brown Project report Hello Mery!! The book is finished!! Content: Let's look at the @STxT@ version: Code: # This is a line comment Email (www.example.com/email.stxt): From: John Smith To: Mery Adams Cc: Keyla Brown Title: Project report Body: Hello Mery!! The book is finished!! Content: I think a first characteristic is immediately apparent: Assert: @STxT@ is much prettier than XML and easier to understand. Content: Let's talk about size. XML Length: 254\\ @STxT@ Length: 190 Let’s see what happens when we compact it as much as possible: Code: John SmithMery AdamsKeyla Brown Project reportHello Mery!! The book is finished!! Code: # This is a line comment Email(www.example.com/email.stxt): From:John Smith To:Mery Adams Cc:Keyla Brown Title:Project report Body:Hello Mery!! The book is finished!! Content: Minimum XML Length: 225\\ Minimum @STxT@ Length: 172 If we compare without XML header or @STxT@ namespace: Minimum XML Length: 186\\ Minimum @STxT@ Length: 149 I think it’s clear that: Assert: @STxT@ is more compact than XML Content: But also: Assert: @STxT@ is more understandable than XML when compacted. Content: Or put another way: Assert: @STxT@ maintains its readability when compacted,\\ while XML does not. Content: By the way, did we lose any information? No, but what would happen if there were attributes? We'll talk about that later. For now, trust me: Assert: With @STxT@, you can express the same as with XML. Content: Now let’s try something fun... What does an XML document look like with a text node that itself contains XML? Let's see: Code: John Smith Mery Adams Keyla Brown Project report Hello Mery!! The book is finished!! <?xml version="1.0" encoding="UTF-8" ?>  <email> <from>John Smith</from> <to>Mery Adams</to> <cc>Keyla Brown<cc> <title>Project report</title> <body>Hello Mery!! The book is finished!!</body> Content: And in @STxT@: Code: Email (www.example.com/email.stxt): From: John Smith To: Mery Adams Cc: Keyla Brown Title: Project report Body: Hello Mery!! The book is finished!! John Smith Mery Adams Keyla Brown Project report Hello Mery!! The book is finished!! Content: I think no further comment is needed. It’s obvious, but: Assert: @STxT@ is simpler than XML. Header: XML Attributes Content: Let’s take an example: Code: Hello World Content: Attributes in XML have always been a source of controversy. What is an attribute and what should be a node? It’s always hard to decide. It is fairly accepted that attributes are like metadata of the node, that is, they provide information but not content. There are cases where this is acceptable, but (in my humble opinion) in most cases they are a source of problems. Another added problem is that everyone has to keep in mind that attributes exist. This affects DTDs, XSDs, libraries, programmers... And for what? They really don’t add much. Just unnecessary complexity. Furthermore, this is @STxT@. Everything has meaning, and everything is important. Assert: @STxT@ does not have attributes in the style of XML. Content: This makes it _BETTER_, not worse. Sometimes, _LESS IS MORE ;-)_ The previous example in @STxT@ would be: Code: example(...): id:1 show:false text:Hello World Content: In general, we can always do something in the form: Code: node_name: metadata: m1:xxx m2:xxx m3:xxx node2: node3: Header: DTD, XSD Subheader: XSD, DTD, and @STxT@ Content: Let’s talk about XML’s DTDs and XSDs. They are documents that tell us how a valid XML should be. They work more or less well, and each has its advantages and disadvantages. If you look around the Internet a bit, you’ll see what I mean. In summary, DTD is simpler than XSD, less powerful, and is written in a language different from XML. XSD is more powerful, harder to make and understand, but it’s written in XML, so there’s no need to learn another language. And what about @STxT@? You should know :-D It has the best. It’s a @STxT@ document. Integrated into the language itself. Powerful and easy to learn. Like @STxT@ itself ;-) Subheader: Where is it? Content: I would like to see a typical XML problem disappear: Assert: _Where is the grammar of this document?_ Content: In @STxT@, _EVERYTHING_ is on the web. When you want to create a document, you must automatically be able to see its definition. The grammar must always be accessible. Assert: A @STxT@ document by definition has an associated grammar.\\ If not, it’s not @STxT@. Subheader: XSD of the XSD (*) Content: Does anyone want to compare the XSD of an XSD? I was tempted to include it in the book, but it would have taken up more than 50 pages, and I’m not exaggerating :-D I’ll leave the link here for anyone who wants to see it: [[http:_www.w3.org/2001/XMLSchema.xsd|http:_www.w3.org/2001/XMLSchema.xsd|xsd]] Is there anyone who understands it? Sorry, sorry. Is there anyone _who isn’t a superhero_ who understands it? Everything is much more complicated. With @STxT@ we have sought simplicity. We like to do things by hand! It shouldn’t be mandatory to have an XML editor or reader! Header: Parsers and Validators Content: Does anyone want to compare parsers and validators? It’s unnecessary. One with @STxT@ is MUCH faster and easier to implement. Why? It’s very simple: Assert: @STxT@ has far fewer rules than XML. Content: This makes everything easier. The parser code is faster. They have fewer errors. It’s easier to maintain. Easier to make. Moreover, another advantage is that parsing and validating can be done simultaneously. With XML, you have to decide whether you really need to validate the XSD... and where is it? We’re back to the same old problem. With @STxT@, everything is much clearer. Every document must have a definition of how it is. But it’s very easy to do. It doesn’t take long. It’s worth it. It’s one of the big advantages of @STxT@. Note: For those who love private information: if the @STxT@ parser or editor has its own @STxT@ grammar repository, it doesn’t have to be visible on the web. I don’t like it; I’m against it, but nothing and no one prevents this from being done. In fact, in some cases, it will be necessary, as I had to do in my own book before the web was published. Header: Namespaces Content: I’ve always hated XML namespaces. They are cumbersome, difficult to control, and usually tell us nothing. Namespaces in @STxT@ are completely different because they are not hard to make, they provide all the necessary information, and you don’t lose the expressiveness that you get with XML. In fact, you don’t even see them! But they are always there, helping. Completing the work. In XML, namespaces are annoying, add complexity, and give very little in return. By the way, we’ve banished the prefix {{{http:_}}} from the namespace. It’s no longer necessary because that would imply it’s different if obtained with {{{http:_}}} than if obtained with {{{https:_}}}. This doesn’t make sense. What does make sense is that it’s from {{{_}}}. Header: The Future Content: I’ve been very honest with my analysis of XML vs. @STxT@, but there’s something we must not forget. XML has been around for a long time. It’s tested, it’s used everywhere. It’s a standard. @STxT@ is new; it has just been born and has a long way to go. But I think it’s worth it.