Mike Shapiro wrote: >> Hiya Mike, >> >> I agree that this is a very interesting and important question for the >> Docs community. Let's go for it! Will you help us to beta a system on >> opensolaris.org, or genunix.org for this purpose? >> >> I copy Brendan, Ben, Al, and Eric as customers, contributors, and doc >> community leaders who are eager to help us develop mechanisms on genunix >> or opensolaris to further the cause of documentation that is easy to >> edit, bug-free, up-to-date, and still meets reader expectations for PDF. >> Can any of you guys help us out? Case of good beer to any takers :) >> > > Of course: I would be happy to help beta-test anything we think might > help in this area, and I know the others folks you've cc'ed would do. > Thank you, but I meant build, not test. I can't give away good beer just for testing! :) We have been investigating a year and a solution to the problem you cite doesn't exist yet or we'd be doing it. We can implement an XML parser for Mediawiki as an extension, but that doesn't get us out of the tagging ease-of-use problem or round-trip issues, FWIU. I honestly believe that to solve this problem today we need some innovative brilliance and coding. But, I'm happy to be wrong and I expect it to change in the future. >> Currently, I just don't have tools to capture changes from a wiki that >> meet 508, PDF, and license requirements, so my plan for the doc and man >> page consolidations was to deliver the SolBook XML in a hg repo using >> the opensolaris project functionality. Thoughts? >> > > My concern around XML is purely ease of editing, particularly for > lowering the barrier to community contributions. And by that I not only > mean ease of editing as in having a WYSIWYG editor, but also the idea that > it's too difficult for most people to learn all the tags, and most of them > aren't needed anyway (I think for the DTrace and MDB guides, totalling > close to 800 pages of content, we used no more than about 20 tags). > I want to see a very simple way to create content without being a DTD > wizard. The *content* is the value -- right now we're letting the > process requirements cripple our ability to empower the broadest > possible audience to create content, and that is what I want to see fixed. > > I would strongly suggest investigating either: > > (a) wiki software that can store the data in docbook XML as the > underlying representation, or > > (b) wiki software that provides enough of a structure in its underlying > representation for a script to extract that data as docbook XML > > That doesn't mean you throw out your other requirements, but rather > find a way to meet them within this new paradigm for content creation. > > -Mike > I will work hard to fix it, Mike. I'll also trade you time to investigate for a willingness on your part to instead encourage *new* MDB and DTrace content on a .org wiki that we link to from the formal XML guides. (best practices, howtos, FAQs, podcasts, screencasts, tutorials, scripts, one liners, tips and tricks). I know I drive a hard bargain, but we could support partners and our 7M users and transition them to the wiki in this way. With genunix and the HTML pages on opensolaris, we are able to empower content creators a great deal, and Google finds both sites. Just need time and helping hands to plan and implement open source wiki software that enables what you describe above on a .org site.
Thanks, Michelle -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/mdb-discuss/attachments/20071205/cbc7c356/attachment.html>
