[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK: Re: doc domain vs. problem domain semantics
>From: Bob Stayton <bobs@caldera.com> >To: "Matt G." <matt_g_@hotmail.com>, ndw@nwalsh.com >CC: docbook@lists.oasis-open.org >Subject: Re: DOCBOOK: Re: doc domain vs. problem domain semantics >Date: Tue, 12 Feb 2002 11:00:02 -0800 > > > >3. The DocBook Technical Committee (TC) is actively maintaining > > >DocBook. If you have a construct for which there is no suitable > > >tag, and the problem domain you are working in is not too far > > >afield, chances are the TC will address the issue. > > > > The problem is that this approach doesn't scale well. That's > > what I'm trying to address. > > > > >4. If you need a new element and either can't wait for the TC to > > >consider it, are if the TC rejects your use case for some reason, > > >you can always add it yourself. > > > > I'd like to see people start maintaining sets of > > application-specific customizations + stylesheets, for DocBook. > > Then, people could assemble packages, which include these > > customization modules and their associated stylesheet modules. > > Of course, without namespaces, this approach won't scale very > > well. > > > > > >>The entire design of DocBook is geared to make it possible for > > > >>you to write customization layers that provide the exact > > > >>markup that you need. Yes, easy to write, but not maintain. Without namespaces, multiple customization modules may not be compatible. Worse yet, a customization module may not be compatible with a newer version of DocBook, due to element name collisions, or there may be similar incompatibilities between future versions of different customization modules. I realize that the core DocBook elements need not have a namespace, in order for these other components to use them, but it's a nice mechanism to formalize subdivision of the vocabulary, and it provides more flexibility, in the future. Another advantage to splitting up the core vocabulary into categories in separate namespaces is the ability it provides for users to more cleanly replace some subset of it. > > I see this as the core competency of the TC. If they do a good > > job with document structure & meta info (and they have), then > > there can be customizations for dozens of fields of every sort. > >[stuff deleted] > >Matt, it's my understanding that you are suggesting >that DocBook become a general purpose publishing system. >You'd like to see it structured in a way that permits >it to be adapted to many kinds of publications, not >just computer-related documentation. Extensibility is the primary benefit of the cleaner modularity I'm proposing. However, I think there are many benefits that come along with partitioning the vocabulary, such as addressing the complaint that DocBook has too many tags. Subdividing them allows users to more easily focus on the tags provided for the task at hand. I'd advocate that the reference part, in TDG, be structured this way, even if the different tag sets aren't put into different namespaces or available as separate distribution modules. Furthermore, existing DocBook users will certainly benefit from more widespread reuse, of the core vocabulary, by others. These benefits are likely to include improvement in tools, documentation, and support. Among other things, I'm concerned that LaTeX is still seeing widespread use, when it's clearly inferior, in nearly all respects, for most applications. I fear that, if the modularity, extensibility, and processing tools, of XML DocBook don't all improve, that the opportunity to succeed LaTeX may be lost (and perhaps to something inferior). >There will be some resistance to this notion, because of >DocBook's origins. It grew out of a consortium of computer >companies wanting a common source format for its >documentation. Those computer companies funded (and continue >to fund through OASIS) the development of DocBook to that >purpose. It is not currently in the charter of the DocBook >Technical Committee to develop a general-purpose publishing >system. I think the move is even justified by only those benefits that are in line with the charter. >As often happens, though, a good tool can be put to new uses. >The DocBook developers did such a good job designing and >implmenting the DTD and the related stylesheets >that they can be used for purposes for which they >weren't intended. The customization features that >were included to enable individual computer companies >to change or add elements to meet their specific >documentation needs also permit anyone to customize >DocBook for non-computer related needs. Such customizations >are permitted and encouraged. > >But that's different from saying that DocBook should be >designed so that it can be adapted to all publishing >needs. As you say, namespaces might be needed to keep I was asking how close it was to being appropriate for all publishing needs. I'm not proposing that anyone should actually try to do this. What I am proposing is that the vocabulary be modularized to improve manageability and extensibility. I would be happy if people were using DocBook as a foundation for all sorts of technical and scientific literature. For this to happen, I believe that substantially more opportunities for reuse must exist. In other words, DocBook clearly isn't a good fit as a foundation for many publishing needs, but it should be a reasonable foundation for many TOPICS about which documents are written. >separate the various modules that could be added. But >namespaces considerably complicate the schema, toolset, and >authoring process. The TC is starting the examine the use >of namespaces for tables, math, and graphics. If those >problems are worked out, then adding other namespaces >would be enabled. I'd encourage the TC to consider hacks, to help smooth the transition and retain interim compatibility with non-namespace aware tools. For example, a transitional DTD could be written to include a namespace abbreviation in the element names of elements not in the core namespace. >Perhaps DocBook should move in the direction of >general-purpose publishing, but I think that is a fundamental >question that the DocBook Technical Committee will have to >settle before it starts restructuring DocBook. As I said, I'm not very concerned about the PUBLISHING end of things, as support for different TOPICS (what I call the "problem-domain"). >As Norm pointed out, DocBook can already be customized to >meet application-specific needs. I agree that the process >could be better documented, and that perhaps a registry of >supported third-party customizations be made available. As stated above, if you want to mix customizations, there is serious potential for collisions. I think it would be valuable for *someone* (not necessarily the TC) to provide tools and documentation to facilitate the development, packaging, and documentation of extension modules + stylesheets. >I'd also point out that DocBook is not the only DTD out >there. The Text Encoding Initiative (TEI) has a modular >DTD that can be mixed and matched to meet many publishing >needs, and contains no computer-related elements that I can >see. 8^) >TEI also has a set of XSL stylesheets that are modularized: ><http://www.hcu.ox.ac.uk/TEI/Stylesheets/teixsl.html> I've heard of it, but haven't looked at it, much. Not that there's not room for TEI and DocBook to co-exist, but I think that whichever makes it easier for users to pick and choose (or develop) modules that naturally fit whatever they'd like to document has the best chance for long-term survival. The nice thing about DocBook is that it tries to capture the structure of print publications. Since this is orthogonal to the more specialized elements, I assume it's possible for one group to develop and maintain a single customization layer that works for both the main DocBook vocabulary, as well as the website version (is this Norm's, or an official TC product?). It might also be nice to replace the core document structure elements, to create a forms markup language, while retaining most or all of the other groups of elements, including most extension modules. Anyhow, perhaps I haven't made a very compelling case for subdividing DocBook, but I'd like to hear what other ideas people have for improving the manageability of the vocabulary without handicapping it. One last thought: I'm not sure I can exactly characterize this, but I just get this uncomfortable feeling about technologies that aren't moving forward to scale beyond their current scope. It's almost like they feel dead. I understand your point about the interests of DocBook's sponsors, but it seems so short-sighted and artificial to me to limit the scope of DocBook, here. It's not yet quite a 100% solution, but it feels like something with so much potential. And then there's part of me that wonders: "why do so much work, only to stop this short of something so big?". I appreciate the thoughtful reply. Matt Gruenke _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC