OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] XML, Rich Internet Apps

[ Lists Home | Date Index | Thread Index ]
  • To: <xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] XML, Rich Internet Apps
  • From: "Chuck White" <chuck@tumeric.net>
  • Date: Mon, 25 Nov 2002 17:10:54 -0800
  • Thread-index: AcKUoFl0GR1R0BrIRUedC4fNCDvjjQAQF0Bw
  • Thread-topic: [xml-dev] XML, Rich Internet Apps

AndrewWatt2000@aol.com wrote:

> You mention HTML as part of the desired output. Why?

Do I want (X)HTML as desired output? Of course. But it can be handled
through a separate process -- I don't think an XSL-FO and/or SVG editor
needs to add that layer.

> In the open source sector Cocoon can provide the XSLT/SVG/XSL-FO/PDF
> - the capital outlay is nil but there is a lot of developer time to
> fully up to speed with Cocoon. But it is being continually developed
so I
> think it is one to watch.

Developer time = Capital Outlay to the bean counters. Unless you're
using developers from India, Russia and the like, the cash outlay on
developer time on Cocoon is pretty tremendous. But this is no knock on
Cocoon. They're doing a remarkable job from what I've seen. 

> There seems to a be a price opportunity for someone here. Surely there
> a space between $0 and $20,000 (or is it $40,000?) for someone to
> something else in this space?

Well, like I said, unless you have Apache people on board already, the
cost for Cocoon is not $0. But I get your point.

> Or that you have slightly underestimated the time to get it to market?

That, too.

> In a sense designers must be *in* the process. I see the question as
> one of how to achieve good design along with good coding (by hand or
> automatic) without each getting in the other's way.

Generally, the design end is not an issue. You simply develop a
Photoshop file as part of your functional design document, and have your
coding people code it. So my original statement was really kind of

> The huge advantage of SVG over generic XML is that human beings (for
> least certain things) think visually.
> "An SVG picture is worth 1,000 XML words!". (c)(tm)

Generally, even the simplest SVG picture *is* at least a thousand XML
words. But more seriously, I think for the purposes of search engine
indexing, etc., it's good to try to promote the idea of the separation
of content and presentation. Not to mention updating content. As much as
I like SVG, my biggest concern with it is that we'll go backwards, and
kill off the idea that content and presentation are separate beasts. So
a minimum requirement in an SVG editor should be the ability to drag
nodes from a data source onto the SVG canvas so we can give nodes their
design properties there. If someone wants to just take a blank canvas
and whip up SVG, that's their business, but I'd like the option to use
data sources for content.

> Surely this is a question of good design.
> Part of the problem with Flash content has been bad / gratuitous

Don't make me waste XML-Dev bandwidth on my distaste for most Flash
design! I won't go there. I won't! :-) 

> "The rest of us" have to look to someone seeing a gap in the market
> between the $0 of Apache Cocoon (which is *not* (yet) safe to let a
> graphic designer near unsupervised) and the $20/40,000 of Adobe's
> Server and/or  Graphics Server.

Well, if the $20,000 is *all* you need to spend on Adobe's product, it
might be worth it, even against the cost of Cocoon, which requires
developer salaries to administer and code. But typically, I have found
that expensive software is expensive to maintain and administer. 

Generally, I insulate my better designers from coding anyway, unless
someone is eager to expand their skills. 
> I am optimistic we will see several such tools in the not too distant
> future. 

I am cautiously optimistic. I subscribed to a very busy Flash developer
list not too long ago when I was working on a Flash project and was
surprised that reaction to SVG, when opinions were solicited, was, at
worst, lukewarm. Concerted resistance among Flash developers would be
another hurdle for SVG to cross, but it's possible that Flash developers
could get quite taken with SVG if only a tool comparable to Flash would
emerge. But there is still virtually no installed base for SVG in
browsers. What's missing is a Macromedia-style push from Adobe to get
the SVG plug-in installed, but they aren't really doing that. Not


Chuck White
Author, Mastering XSLT, Sybex Books
Co-Author, Mastering XML Premium Edition, Sybex Books


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS