> Q: Is this discussion about writing just another HTML editor, or about > building an abstracted content editor where structure, layout and > style can > be assembled from the contributions of multiple authors (using XML, XSLT, > etc., of course). The real trick is to build a really neat (and > usable) XSLT > editor for writing the stylesheets that enable abstract data (XML) to be > generated into human readable form.
I agree, somewhat: shouldn't the discussion be about an 'abstracted content editor' _API_. That is, shouldn't this thread cross back to an older thread about a CMS API? Design and build the API, make it available using XML-RPC or SOAP, and leave the editor to the user's choice. In fact, let people build their own dream version. I might like to integrate my CMS with Jabber, or a Swing client, or a desktop app, or a browser based version. I would argue that part of the Java story (esp. J2EE) is to define the plumbing and then let them implement it. There's no need for this group to build everything end to end; define a rock solid, simple API and you'll see editors appearing quickly after. Specifics: the newest tech in IE that I like is the ability to call web services (through 'behaviors'). If you take Stefano's granularity to the extreme, every editable XML atom on the 'page' should have associated get/set/edit implementations accessible through web services. Fire away, Per --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
