RE: DOCBOOK: Re: packagename proposal/RFE

["Matt G." <matt_g_ at hotmail dot com>]

> From: "David Cramer" <dcramer@broadjump.com>
> To: "Bob Stayton" <bobs@caldera.com>, "Matt G." <matt_g_@hotmail.com>,   
> <jirka@kosek.cz>
> CC: <docbook@lists.oasis-open.org>
> Subject: RE: DOCBOOK: Re: packagename proposal/RFE
> Date: Thu, 6 Jun 2002 11:05:55 -0500
>
> I'd like to second that point. Compare <oointerface> v. <interface>.
> Consistency seems to require <oopackage>.
To me, there seems to be nothing fundamentally object-oriented, about the 
programming concept of a 'package'.  In fact, I'm not sure it's worth making 
the semantics of a new package element so specific that it couldn't be used 
interchangeably to describe both Java packages and software packages.  
Correct me if I'm wrong, but it seems like Java really borrowed the term 
from the fact that libraries were released as something often referred to as 
a "package".

If a package element is added specifically as a programming-language 
construct, then I'd rather see it called something like 'interfacepackage'.


Gee, it's a shame to consider that this whole discussion could have been 
precluded by use of XML namespaces.  Then, a java:package would be distinct 
from a sw:package, and each could have arbitrarily specific semantics, 
without any confusion.

In order to efficiently scale, DocBook & tools support for XML namespaces is 
essential.  See my proposal for the decomposition of the current DocBook 
vocabulary:

   http://lists.oasis-open.org/archives/docbook/200202/msg00064.html


The idea, then, would be for lots of communities to have projects to provide 
their own elements.  This would allow DocBook to scale much faster and 
larger, by distributing the effort of maintaining separate modules, for 
different topics.  The whole thing would be much more manageable, too, since 
the scope of each vocabulary module would be constrained by its namespace.

The challenges that must be overcome, to realize this goal, are not 
insignificant:
   * DocBook tools support for XML namespaces (this generally comes for 
free,
     with XSL, however I think support for W3C Schema Language is still 
sparse)
   * The DocBook needs to be specified in a well-supported 
namespace-friendly
     schema language
   * DocBook documentation should be provided in a modular source format, 
along
     with tools for helping module maintainers document their packages in a
     similar fashion.  Then, users/distributions can produce comprehensive
     documentation conveniently specifying the entire set of elements 
included.

In addition to providing a schema module and the corresponding modular 
documentation, module maintainers will also want to provide a stylesheet 
module.

Well, that's my vision, anyhow.  I recently expanded the scope of a DTD 
documentation tool project, with which I'm involved, to encompass other 
schema languages, such as the W3C XML Schema Language, and RELAX NG.  I 
don't know much about either of those, so I definitely have some reading to 
do.


Matt Gruenke


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx