Slashdot Mirror


Online Comics Syndication in XML

gravling writes: "Jason McIntosh has written an interesting article on XML.com about ComicsML, a language he's invented to allow online comics artists to describe and syndicate their work. Using ComicsML can let you do similar things to the UserFriendly search engine, but on a web-wide basis."

2 of 57 comments (clear)

  1. ANOTHER grammar? by Smoking+Joe · · Score: 5

    By the Great Spirit, do we really need another XML grammar? Do we really need another obscure specification sitting on another server that will be down 10% of the time and cause parsers to choke, programs to hang, and tech-support desks to light up like Christmas trees.

    I'm sorry to go off on such a rant, but I am SO tired of everything being done in an XML format. It's not that it's a particularly great solution, it's just that it's the new hot standard. Furthermore, let's face it, XML is real easy. So easy that very mediocre minds can grasp it and feel like they're "on top" of the current technological trend.

    Puh-leeze

    As a result we now have a plethora of half-baked, almost-finished grammar specifications littering the internet landscape and plugging up the W3C standards pipelines.

    I'm making a predication. Most of these standards will either (1) be forgotten or (2) be rushed through and signed off as standards. I hope and meditate for the first.

    XML is great for some types of data, but it's advocates are so blinded by its simplicity and consistency they overlook flaws immediately obvious to more experienced developers. Despite the press, XML is NOT that easy to parse. The same hassles we experience with HTML parsers are magnified tenfold. Furthermore, it often depends on grammar definitions that reside on remote servers. This introduces all the hassles of network-based programming into what should be simple standalone client applications. Finally, it's big. I mean REAL big. Oh, you can zip it? Great, let me run out and link the zip libraries into my application. What? There's licensing issues? Well, what do I do know?

    Please, for pete's sake, when you feel the temptation to create another XML grammar, think about what you are doing. Just say no. Your users will thank you.

    --
    If the lameness filter actually worked, would you even be reading this?
    1. Re:ANOTHER grammar? by Ergo2000 · · Score: 5

      By the Great Spirit, do we really need another XML grammar?

      It's a schema (unfortunately apparently just a DTD). Backgrounder (which is probably unnecessary for you but for others that will misread your message and assume you are implying that there's all these crazy "standards" for XML) : XML is merely the basic rules by which the data is encapsulated, but without agreeing on a standard set of data organization standards (schemas) you really haven't acheived much (and this is something that most XML zealots and detractors fail to understand). If I said "Give me your resume in that new whiz bang `XML format'" I will have achieved nothing and would get a huge mess of sloppy data piles that would have to be analyzed, etc. One might be a binary Word document enclosed in the root tag, while another one might be heirarchial with tonnes of attributes, etc ("object oriented"). If on the other hand I said "Give me your resume conforming to the schema blah blah (giving a namespace like http://www.hr-xml.org/blahblah.xsd) you will know EXACTLY the format that your data should be encapsulated in, that the xsd:timeInstant field is ISO 8601, that the character set can be encapsulated just so, that the character field must follow specific rules, that it must have this set of fields in this order : I can then build a validation engine (that will have a local copy of that schema obviously : I can't see any situation where you'd be working with remote schemas. At most you will view it as a namespace. Schemas once published become like a COM interface : immutable, and when I say that my program conforms to MonkeyShema 1.0 at the namespace location of blah blah then I have that intrinsincally in the logic of the program and noway would I do a get of that schema everytime I wanted to parse something) that says "Does this conform to the rules?" and from there it can parse through it sucking out the values into the HR database. XML + XSD is the standard, and an absolutely brilliant one, that despite the frothy rantings of critics, is incredibly valuable. XML+XSD+XSLT is offering a solution that the industry has never had, certainly not this evolved.

      As mentioned though the true power of XML is really in the schemas : The standard way of defining the data (see http://www.w3.org/XML/Schema). When people have such a clearly defined, standard method of describing communications between two products that is of immeasurable value. The idea behind each of these schema standards is to do exactly that : Start agreeing on some basic standard schemas. See Biztalk.org for examples.

      Your opposition sounds primarily to be fear of change (which is one of the most imposing software development problems). XML+XPath+XSLT+XSD is quite a load to learn, so firstly I take issue with your claim that XML is "simple" : Can it be simple to start into? Absolutely. Just like C can be easy to start into.

      int main(int argc, char *argv[]) {
      &nbsp printf("Hello world!\n\r");
      };

      Does that diminish the power of C? Not in the slightest. XML represents a great leap forward in our ability to describe the data that we pass back and forth, and the standards are of enormous value.

      BTW: Obviously eventually some fully spec'd XML compression will be standardized, such as XMill. XML is heavily compressible : Often, paradoxically, moreso than the same data stored in a proprietary format. However it is usually a moot point because XML usually comes into play where no existing communications were taking place.

      Cheers!