RE: [dita-fa-edboard] DITA wiki

[Don Day <dond@us.ibm.com>]

I'll make the obvious connection that the demo at the end actually could be
implemented dynamically:

DITA source topic > [DITA-OT] > HTML source view > [html2wiki] > wikitext
source

Unfortunately, this is not a round-trippable solution--you cannot turn
hamburger back into the cow.  This works best for publishing existing DITA
into existing Wikis as a one-time process, such as publishing drafts into
Wikis for collaborative review. Capturing the edits back out into revised
DITA is the place where Wiki as source falls flat.

Regards,
--
Don Day
Chair, OASIS DITA Technical Committee
IBM Lead DITA Architect
Email: dond@us.ibm.com
11501 Burnet Rd. MS9033E015, Austin TX 78758
Phone: +1 512-838-8550
T/L: 678-8550

"Where is the wisdom we have lost in knowledge?
 Where is the knowledge we have lost in information?"
   --T.S. Eliot


                                                                           
             "Carol Geyer"                                                 
             <carol.geyer@oasi                                             
             s-open.org>                                                To 
                                       "'Su-Laine Yeo'"                    
             07/11/2007 10:20          <su-laine.yeo@justsystems.com>      
             AM                                                         cc 
                                       "'DITA Editorial Board'"            
                                       <dita-fa-edboard@lists.xml.org>     
                                                                   Subject 
                                       RE: [dita-fa-edboard] DITA wiki     
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Su-Laine,
Excellent! This is just what we need.

I have forwarded this to the OASIS IT guys and will discuss it with them
before
our EdBoard call tomorrow.

Thanks so much,
Carol

-----Original Message-----
From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com]
Sent: Tuesday, July 10, 2007 10:54 PM
To: Don Day; Scott Prentice
Cc: Carol Geyer; DITA Editorial Board; Bruce Esrig
Subject: RE: [dita-fa-edboard] DITA wiki

Hi,

( I'm back in this world after being buried in other projects for a
while :)   )

If our primary goal is "empowering "contributing users" to add content
(in the self policing spirit of wikipedia) to help the DITA community
feel more  ownership of the site," and to improve the quality and
usability of documentation through collaborative editing, I think our
chances of reaching that goal will be influenced by the software we
choose. The alternatives we've discussed so far are: 1)  a Drupal-based
wiki, 2) MediaWiki, which is used by Wikipedia, and 3) a web-based DITA
editor, presumably within an infrastructure which allows people to check
out XML pages, edit them, and check them back in.

At the last meeting, I took an action item to articulate some of our
requirements for wiki software. Here is a start:

Visibility of changes
- Be able to view all revisions in a page's history
- Be able to view a precise diff between any two revisions
- Watchlist pages. Be alerted to changes on the articles you declared as
interesting
- Recent changes list - See all changes recently made across the site,
including diffs

Discussion
- Have a discussion area for each page
- Make it easy for people to sign their comments with their username and
date stamp

Editor
-  Easy-to-use page editor. In particular, it should be very easy to
make links between pages on the same wiki.

Categories
- Allow assigning any page to an arbitrary number of categories.
Categories allow classification and hierarchical browsing of the
content.

Protected Pages
- Administrators should be able to protect a page, making it uneditable
except by other administrators. Usually the discussion area of a
protected page can still be edited.

User identification and accountability
These features foster relationships and help the community recognize
good contributors.
- Provide a page for each user to say something about who they are.
- Be able to view a list of a user's contributions to see who the good
contributors are and what are their areas of expertise. Also see who are
the problem editors (vandals and spammers).

Bad-guy fighting
- Blacklisting for spam sites
- Ability to block named users and IPs

MediaWiki can do all of these things, and a lot more. It's proven itself
on Wikipedia, which at the last time I checked was getting over 100
edits per minute. Drupal can probably do some of these things.
Unfortunately, I don't think anything based on DITA can come close at
this time.

I've been investigating the options for converting the DITA core
documentation into wikitext. So far the most promising option seems to
be this one:
http://search.cpan.org/~diberri/HTML-WikiConverter/lib/HTML/WikiConverte
r.pm#___top .

A quick demonstration of its output is here:
http://scratchpad.wikia.com/wiki/Image_element . I created this by
transforming the source from
http://docs.oasis-open.org/dita/v1.0/langspec/image.html using
http://diberri.dyndns.org/wikipedia/html2wiki/ .

Lots to talk about!

Cheers,
Su-Laine

Su-Laine Yeo
Interaction Design Specialist, XMetaL

JustSystems, Inc.
Office: 778-327-6356
su-laine.yeo@justsystems.com
http://na.justsystems.com



-----Original Message-----
From: Don Day [mailto:dond@us.ibm.com]
Sent: Wednesday, June 27, 2007 3:09 PM
To: Scott Prentice
Cc: Carol Geyer; 'DITA Editorial Board'; 'Bruce Esrig'
Subject: Re: [dita-fa-edboard] DITA wiki

That is a very good idea, Scott. When DITA Storm was first introduced,
it
had a very limited set up tags at the time, and so the user experience
was
in fact like using a very simple markup language. The current
implementation still is not at full DITA, but it can be "dummied down"
as
much as we feel is necessary by simply using a simpler "model.xml" to
define which elements are actually exposed to the user. If we can
articulate a "minimum tag set" that is part of a valid topic context, we
can express just that degree of function through the DITA Storm editor.
It
is an elegant alternative to "subsetted DITA" which has the problematic
overhead of creating a non-DITA DTD to try to dummy down the experience
of
structured authoring on a full XML editor. The DITA Storm approach is
much
more ground-up, hence much smaller footprint/effort overall.  If we
discuss
a subset of the full topic with Alex's team, they'll understand exactly
what is needed. Then we can switch that sandbox mode over to a
production
mode once we think it is doing what we need.

Regards,
--
Don Day
Chair, OASIS DITA Technical Committee
IBM Lead DITA Architect
Email: dond@us.ibm.com
11501 Burnet Rd. MS9033E015, Austin TX 78758
Phone: +1 512-838-8550
T/L: 678-8550

"Where is the wisdom we have lost in knowledge?
 Where is the knowledge we have lost in information?"
   --T.S. Eliot




             Scott Prentice

             <sp@leximation.co

             m>
To
                                       Don Day/Austin/IBM@IBMUS

             06/27/2007 03:44
cc
             PM                        Carol Geyer

                                       <carol.geyer@oasis-open.org>,

                                       "'DITA Editorial Board'"

                                       <dita-fa-edboard@lists.xml.org>,

                                       "'Bruce Esrig'"

                                       <esrig-ia@esrig.com>


Subject
                                       Re: [dita-fa-edboard] DITA wiki

















I think that the ability to author DITA files in an online environment
is technically a cool and interesting thing to do, but I'm not convinced
that it is actually a good idea in practice for a publicly-maintained
set of web pages. The biggest problem that I see is that it offers way
too many tagging options, and the resulting content may not be very
usable. One way to mitigate the problem may be to expose a very pared
down set of tags. If this were only used by a limited group of people
who agreed on tagging standards, it could work nicely, but for the
general public use I think it would be more trouble than its worth.

I don't mean to discourage this development, because it would be really
nice to be able to provide this as a prototype for a web-based authoring
environment. Maybe we should start by setting this up as a sandbox
testing area and see where it can go from there.

...scott


Don Day wrote:
> Might it be worth re-engaging Alex Karezin on his offer to implement a
DITA
> Storm sub-feature in the server, whereby users could create the
hierarchy
> and link to actual DITA source under the covers? There is still the
issue
> of who to make this content access available to, but it would be a
great
> step forward in "eating our own dogfood."
>
> Regards,
> --
> Don Day
> Chair, OASIS DITA Technical Committee
> IBM Lead DITA Architect
> Email: dond@us.ibm.com
> 11501 Burnet Rd. MS9033E015, Austin TX 78758
> Phone: +1 512-838-8550
> T/L: 678-8550
>
> "Where is the wisdom we have lost in knowledge?
>  Where is the knowledge we have lost in information?"
>    --T.S. Eliot
>
>
>

>              "Carol Geyer"

>              <carol.geyer@oasi

>              s-open.org>
To
>                                        "'Bruce Esrig'"

>              06/27/2007 10:36          <esrig-ia@esrig.com>, "'DITA

>              AM                        Editorial Board'"

>                                        <dita-fa-edboard@lists.xml.org>

>
cc
>

>
Subject
>                                        RE: [dita-fa-edboard] DITA wiki

>

>

>

>

>

>

>
>
>
>
> I realize our original goal was for the KB to represent the organized
> thoughts
> of the EdBoard, but I fear those pages have grown stagnant (and many
remain
> stillborn). Empowering "contributing users" to add content (in the
self
> policing spirit of wikipedia) might help the DITA community feel more
> ownership
> of the site.
>
> I'm also not sure it's clear to users why some information is in the
KB
and
> other information is in the wiki pages.
>
> I think Drupal 5.1 will give us more options WRT navigation and menus.
We
> can
> explore this once the site has been transitioned. Maybe we could add
an
> expandable left nav back into the theme.
>
> If we can improve the navigation, would it make sense for the
Editorial
> Board
> to spend time composing a more comprehensive hierarchy for the site
and
> adding
> "stub" pages in places where we don't have content but would like to
> encourage
> it?
>
> Carol
>
> -----Original Message-----
> From: Bruce Esrig [mailto:esrig-ia@esrig.com]
> Sent: Wednesday, June 27, 2007 9:56 AM
> To: Carol Geyer; 'DITA Editorial Board'
> Subject: Re: [dita-fa-edboard] DITA wiki
>
> 1. I think this should be done in the wiki, not in the knowledge base.
>
> The knowledge base is constructed as a tree of book pages. It has a
> definite hierarchy, which the user can navigate using the up, prev,
and
> next links at the bottom of the page. (Also, the knowledge base
represents
> the organized thoughts of the editorial board, for better or worse. If
we
> want to allow certain people to edit the knowledge base, we should
make
> them "contributing users" and use those permissions to enable their
> activities within the knowledge base.)
>
> The areas that we have divided the wiki into are not separated in this
way.
>
> The relationships are quite fluid. How you get to a wiki page matters
less
> than what links you see when you get there. We don't have a way right
now
> to show the user how to navigate back from a wiki page to the wiki
pages
> that point to it, so if someone arrives on the site at a wiki page,
they
> have to do their own work to find out where they are. That's why I've
been
> advocating format standards for wiki pages that emphasize the value of
> links from a page to the context for the page.
>
> 2. I don't know where we stand with regard to Zak and his proposed
> contribution. I might have left him with a choice that he doesn't know
how
> to answer.
>
> Best wishes,
>
> Bruce
>
> At 08:37 AM 6/27/2007, Carol Geyer wrote:
>
>> Should we consider allowing registered users to directly edit and add
>>
> pages to
>
>> the Knowledge base (essentially merging our Knowledge base and Wiki
>>
> sections)?
>
>> This would be a simple matter of changing permissions on the
registered
>>
> user
>
>> role. The Editorial Board could review new posts on a regular basis
and
>>
> adjust
>
>> the site's navigation to accommodate them (or work out something
similar
>> to the
>> way wikipedia uses "stubs" to embrace navigation to new pages).
>>
>> We could put the spec itself in a different section where only
appended
>> comments (not direct edits) would be allowed.
>>
>> Does that make sense? What would a wiki give us that this approach
would
>>
> not?
>
>> --c
>>
>> _________________________________
>> Carol Geyer
>> Director of Communications
>> OASIS
>> +1.978.667.5115 x209
>>
>>


---------------------------------------------------------------------
This publicly archived list is provided by OASIS for the use of the
Editorial
Board of DITA XML.org. Subscription and posting privileges are reserved for
members of the Editorial Board; others should contact
communications@oasis-open.org for assistance.

[Un]Subscribe: dita-fa-edboard-[un]subscribe@lists.xml.org
List archives: http://lists.xml.org/archives/dita-fa-edboard/
XML.org DITA Focus Area: http://dita.xml.org
Committee homepage: http://www.oasis-open.org/committees/dita
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php