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

["Chuck White" <chuck@tumeric.net>]

> -----Original Message-----
> From: Danny Ayers [mailto:danny666@virgilio.it]
> 
> First of all I must say it's very refreshing to hear comments from
someone
> tech-savvy who's working in a field like graphic design who is
prepared to
> look at the technologies without religious dogma.

Thanks. It's all just a big accident. There's a lot of creativity in
programming, especially in XSLT. I'd love to see more graphic designer
types make the leap, but numbers scare most of us.
 
> But there you're talking of systems we already have - producing XML
from
> data sources is the stock-in-trade of a probably a high proportion of
the
> people on this list. I think I can safely assume you've mastered XSLT
;-)
> It is necessary to see what the results look like, but something like
the
> Adobe browser plugin will do that. Ok, I do agree that there's still a
lot
> that could be done tool-wise to keep the designers away from the
> programmers
> (and vice versa), but the tools XML folks already use cover quite a
> sizeable
> chunk of the requirements.

Yes, the systems are there, but they need to be cobbled together. I can
do that, and anyone on this list can, I presume, but most graphic
designers I know wouldn't have a clue where to begin. And then there's
the whole design pattern question. Do we even want designers (I am one,
so I am not bashing these people here) to be involved in data modeling?
Probably not. So here is my fantasy all purpose publishing IDE:

* It can read XML data sources
* It has a drag and drop interface with a property and methods
management panel similar to what you see in development IDEs that lets
you place an object (node) onto a panel and position it as you wish.
* It has a timeline
* It outputs it to at least SVG, but my real fantasy is that it outputs
to XSL-FO and HTML and has a hook into something like FOP. And if we
really want to get silly, maybe it even outputs to SMIL. 

I know I'm wishing for the moon here. One problem is that I haven't seen
any kind of visual-based XSLT tool I would be willing to trust, and the
above would require one built in to the process. I've looked at a few,
and have quickly gone back to coding, but that may stem from my internal
bias against visual editors that began somewhere along the time I tried
out my first WYSIWYG HTML editor. But it probably has more to do with
that I just find so much creative challenge in building XSLT docs by
hand.

So basically, I guess my fantasy is sort of an amazing, magical XSLT
transformation tool that outputs XML from a visual interface into a
variety of formats -- SVG, HTML, SMIL, PDF (through XSL-FO). I have to
assume that is either an amazingly difficult piece of software to write,
or that nobody has seen an appropriate ROI value in it.

Anyway, I would at least like to see an SVG tool that is like that. Sort
of a data-driven WebDraw. And with avenue.Quark and Adobe's InDesign
2.0's XML plug-in we're close to repurposing page layout, but I haven't
figured out how to keep designers out of the process using those tools
(this goes back to my "we really don't want graphic designers modeling
XML, do we?"). 

> 
>  The real power of XML in
> >publishing seems to me to be the repurposing of documents. Just
> >saying SVG is XML isn't a good justification for using it. I want
> >to repurpose documents so that I can store them as XML and send
> >them out as Flash/SVG, PDF, and HTML. We're not there yet.
> 
> We're very, very close. Transforming XML docs to HTML is usually
trivial,
> to
> SVG it isn't much harder. FOP (Formatting Objects Processor) [1] can
do
> stuff like SVG, PS & PDF already. There may be problems using Flash as
a
> target format for technical and/or legal reasons, I really don't know.
All
> this stuff can be data driven, server or client, just patch in your
> existing
> data sources.

Again, that's something *I* can do, but it's not trivial for typical
designers to patch this stuff together. FOP is great -- I've used it
since the days James Tauber was slaving away on it on his own back in
the early days of XSL-FO (before it was called that). But try to explain
what a class path is to a typical graphic designer. You'll just end up
shrugging your shoulders and having a drink together.
> 
> But it
> >seems like we could be. Of course, who's going to write this
> >software? Not me, certainly.
> 
> I don't see why not! (heh) - the majority of applications are dead
easy if
> you know XSLT and/or DOM.

Okay, you're right -- I can write stuff to make all of this work, and I
have. What I meant was that I am not capable of writing an executable to
make it all happen at once. Although, if I had Adobe's money (or one day
of Bill Gates' earnings), I bet I could put the team together that
could.

> 
> btw, here [2] are some simple server-side demo apps. The slide maker
takes
> form data, wraps it up in <tags/> and then applies simple XSLT to get
the
> SVG. Though it wasn't necessary it uses HTML as an intermediate
format, so
> although it's not shown in this demo there are two of the publishing
> formats
> you mentioned available. An viewer is needed - the (free) Adobe
browser
> plugin is probably the least effort, it works transparently inside
> Internet
> Explorer.

I've done some data-driven SVG myself using XSLT. I wish I had a little
more time to play with that. 

So yes, I agree that all the systems really are in place for everything
I am talking about. What I am dreaming of is binary executables that are
within the grasp of the people who could really make the stuff we talk
about on these lists get used every day. Making things like SVG, XSL-FO,
and even XSLT more accessible to non-programmers would be a very good
thing. I think that the data-driven part of this equation is very
important. I don't see any particular benefits to simply cobbling
together SVG for the sake of SVG because it happens to be XML. I might
as well use Flash. In other words, I don't want arbitrary content in my
SVG files. I would prefer that writers create and update their content
in an XML document and bring it in to whatever design program is being
used.

I've read about Adobe's Document Server, and maybe that does all or some
of what I'm talking about. But I haven't seen it, and it's 20,000 US
dollars. Not a small investment for people to make. And that doesn't
include the cost of hiring an IT person or two to make it work, or the
training it would require to get staffers to use it properly. It sounds
more like a product for Lockheed than an ad agency (my typical
hang-out). 

Cheers,


Chuck White
-------------------------
Author, Mastering XSLT, Sybex Books
Co-Author, Mastering XML Premium Edition, Sybex Books
http://www.javertising.com/webtech/