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."

5 of 57 comments (clear)

  1. Usar Freindly? by Trepidity · · Score: 4

    User Friendly, eh?

    Usar Freindley, Lunix friend.

    (Yuo are WORST comic evar.)

  2. Does anybody read "real" comics anymore? by Victor+Ng · · Score: 4
    What the hell is this? One of the core elements of comics is the panel layout. The author of the article makes the concession that ComicML doesn't support proper panel layout, but this is a ludicrous limitation.

    The only comics that do not heavily use panel layout are the 3-6 panel comics found in newspapers. All of the mainstream comics that are popular on the newstand from Marvel, DC or any of the other publishers require laying out 28-32 pages with ~6 to 10 panels per page.

    Panels are not necessarily rectangular, they may not align nicely. ComicML seems to actually reduce the expressiveness of a dead tree medium for the sake of making it techie cool with XML.

    an unabashed comics fan,
    vic

  3. 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!

  4. Hmm... this pretty blatantly ignores manga. by Bonker · · Score: 4

    I can't account for everything a comics artist can pull off, of course, but I did try to cover the major, conventional visual idioms that have developed in Western comics over the last century.

    I think this line pretty much speaks for itself, but I will raise a few more points. The internet has allowed comics to pretty firmly break the traditional limitations of print. This DTD seems to want to codify everything inside those old limitations. That's a pretty limiting point of view, I think.

    Where are the tags to show art that crosses multiple panels? Where are the tags to show 'visual' thought bubbles. Where is the anime-style giant sweatdrop tag? Where are the tags to show 'emotional' sound effects, as are often displayed in manga and manga-based comics?

    Unfortuneately, this DTD pretty firmly ignores everything that doesn't go along with western newspaper-style comics, despite the fact that the author wants to let people break out of those old traditions.

    Bzzt! So sorry, but you lose! Please play again, McIntosh-san!

    --
    The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!