This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: DocBook Editor?


>         I agree with you. But we need an XML word processor for
>editing DocBook documents; some call them "Document editor"s and
>that's what we really need.

Wait, who's "we"?  The DocBook community, in general?


>I know vi, emacs, name_your_editor_here rock and I use them
>myself, but wouldn't it be cool to have a nice word processor-like
>XML DocBook editor?

Um... no.  Just kidding.  ^_^   The thing is that it'd be lots of work to 
really do it "right".  In order not to loose nearly all of the potential 
benefits of using XML DocBook, in the first place, a DocBook editor would 
basically have to go to great lengths to translate user input into the most 
minimal edits of the source files.  Entity references would have to be 
preserved, though not visually, but the user would have to be queried, when 
editing across an entity boundary, whether it intends the edit to modify the 
entity, or to expand the entity and edit that, etc.  One would also need to 
be able to insert and remove entity references.

I think it wouldn't even be worthwhile to bother with an internal subset 
editor, but then how to deal with overrides of definitions, in marked 
sections, of parameter entity references used in definitions of general 
entities that the user is trying to modify...  what a headache!


Perhaps an alternate approach would be to write an entity-oriented editor, 
instead of trying to treat the entire document as a single, uniform object.  
For entities referenced within the entity you're editing, you could see the 
value, but not modify it, until you switch to editing that entity.


But, I doubt anyone is going to write a tool that gets it right.  If they 
do, how likely do you think it is that there won't be at least a few 
substantial usability issues (such as international support, rendering 
quality, vi command-mode support, etc.)?

On top of it all, when users are faced with a presentational view of their 
content, they're more likely to write in a presentational fashion, as 
opposed to a structural/semantic one.


Still, there are just some people who don't need to use entities, and won't 
edit raw XML.  Also, I guess using DocBook as an open interchange format, 
instead of a proprietary one (i.e. MS Word), or a weaker one (i.e HTML), 
isn't an awful idea.  So, maybe even a sub-optimal DocBook editor has a 
place in the world, though I worry about people trying to use it when it's 
really not the right tool for the job.


Matt


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]