forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Noels" <stev...@outerthought.org>
Subject RE: [] Dynamic system with WWH (what we have)
Date Thu, 16 May 2002 19:33:16 GMT
Just an idea:

My favourite textwriting oriented XML editor (XMetal3) has a 'track
changes' feature (just as the revisions facility in Word), which uses
processing instructions to highlight changes in the XML-document.

original document:

<?xml version="1.0" encoding="UTF-8"?>
<slide>
  <title>What is Cocoon</title>
  <list>
    <li>XML-based web publishing framework</li>
    <li>XSLT all-the-way</li>
    <li>Based on the SoC principle</li>
    <li>Java Servlet based, but can be run from the commandline,
too</li>
    <list>
      <li>Pre-compilation</li>
      <li>Generation of static site image</li>
    </list>
    <li>Based on Avalon, the Jakarta <em>server application
framework</em> (<link
href="http://jakarta.apache.org/avalon/">http://jakarta.apache.org/avalo
n/</link>)</li>
  </list>
</slide>

after some modifications:

<?xml version="1.0" encoding="UTF-8"?>
<slide>
  <title>What is Cocoon</title>
  <list>
    <li>
    <?xm-insertion_mark_start author="Steven Noels"
time="20020516T212442+0100"?>here, I added an item to the
list<?xm-insertion_mark_end?>
    </li>
    <?xm-deletion_mark author="Steven Noels" time="20020516T212455+0100"
data="&lt;li&gt;XML-based web publishing framework&lt;/li&gt;"?>
    <li>XSLT all-the-way</li>
    <li>Based on the SoC principle</li>
    <li>Java Servlet based, but can be run from the commandline,
too</li>
    <list>
      <li>Pre-compilation</li>
      <li>Generation of static site image</li>
    </list>
    <li>Based on Avalon, the Jakarta <em>server application
framework</em> (<link
href="http://jakarta.apache.org/avalon/">http://jakarta.apache.org/avalo
n/</link>)</li>
  </list>
</slide>

I know in the CALS DTD, there exists markup elements for this too. But
it's long time ago I've been playing with that.

> We still have to think about the additional demands such a
> "distributed
> CMS" would place on the commit process. As with previous
> discussions on
> cocoon-dev, some are advocating that we patch first and deal with
> effects second. If any community member is allowed to patch
> any document
> in cvs, it would require that some committer subjectively review the
> patch before it can be committed. That may take a lot of time, if
> committer resources are low. For example, let's say you received ten
> QA-type patches from ten different community members for the *same*
> page. I don't even want to think how a cvs would merge diffs from so
> many docs. For documentation, it seems that evaluating diffs are a
> judgment call.

My personal subjective preference is towards distributing the
responsability of ack'ing patches. Nicola already knows my fear of
someone getting hit by a bus, the documentation follow-up shouldn't be
centralized neither.

> It also gets complicated when QA impacts multiple
> pages/internal links,
> etc.
>
> However, if we could model community QA content (for existing
> docs) as a
> separate document -- revision -- we could safely and quickly
> aggregate
> timely feedback into with existing doc content (showing up as
> comments
> at the end of the article, e.g.), Each QA patch is just a new
> revision
> doc with hooks to the existing problematic doc/page. Right
> now, I have a
> revisions/revision structure in my howto.dtd. However, we could pull
> revisions out and allow revision docs to stand on their own.
> That way,
> revisions could be applied without hesitation, and, from time
> to time,
> "merged" into existing doc content when a committer/editor
> has the time.

Yep, we should provide some lightweight XML markup for indicating
revisions, preferably in-place instead of grouped at the end of a
document.

I'll check if I find back how this was done in CALS.

</Steven>


Mime
View raw message