Re: [docbook] Ruminations on the future of DocBook

[ed nixon <ed dot nixon at LynnParkPlace dot org>]

<RantToFollow/>

Steve, For a "speaking for myself" post, this sounds pretty 
unequivocally like "speaking for someone else."

If the DocBook system is so heavily invested with interests of 
organizations that provide direct support, "breathing space" support or 
who have economic interests via products that contain "applications", 
what chance is there that (by consensus) much needed changes will be 
anything other than more cosmetics and those shaped by back-channel, 
off-line turbulence?  I'd like to be wrong, but at this point this looks 
like an open-source change initiative that is in danger of foundering 
before it begins.

Why are there all these posts about solutions when there is so little 
understanding or consensus about how this is all going to happen, to be 
managed? If the change process itself is not pretty clearly defined 
including the definition of the goals to be achieved, then everything 
that comes down the line with "[docbook]Ruminations" in the subject line 
is going to be rapidly asymptotic to chewed grass. IMHO.

Constructive suggestions, made in good faith (yes mine, for example 
about cutting back to an XHTML mapping) deserve more than a polite reply 
or two to highlight the thundering silence and lack of discussion. On 
the other hand, if I'm mistaken and the purpose of this thread is simply 
to inform rather than gather feedback, why not just get on with the 
changes and report back when they're done? It should be clear that an 
unstructured and free flowing mailing-list is not the way to collect 
real input, requirements or feedback. Can we not put the list's 
magnificent technical expertise and experience to work to create a 
consultation that is open, works and even arrives at a decent solution?

Regards.                     ...edN


Steven Cogorno wrote:

> Jeff Biss said:
>  
>
> > Michael,
> >
> > I understand what you're saying but I am talking about the hierarchy of 
> > the docBook. There could be just one element that would have a default 
> > attribute unless it is provided with an override. The complexity would 
> > be shifted from the elements to the attributes. This may not be an 
> > answer for every element but at the moment there is such a reduction. 
> >    
>
> And what advantage does this give?
>
> Chaging warning and note to a single element with an attribute does nothing
> to simply the processing.  What it does do is prevent orgaizations from
> customizing the DTD to restrict where one or the other might appear.
>
> Just as Norm was not speaking for his employer, I am not officially
> representing Sun Microsystems in this message.
>
> I think it's important to recognize the extensive investments many companies
> have made to implement DocBook and DocBook-based DTDs. I estimate that my
> department (not Sun as a whole) has spent ten million dollars developing and
> supporting our documentation tools in the eight years we've been using
> DocBook.  We produce over 100,000 pages of content a year. We have gigabytes
> of structured documentation.
>
> I suspect management would be extremely reluctant to adopt such fundamental
> changes that would significantly de-leverage the existing investmest.  
>
> Steve Cogorno
> Sun Microsystems
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-help@lists.oasis-open.org
>
>
>  



---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-help@lists.oasis-open.org