OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: DOCBOOK: Re: packagename proposal/RFE

>From: "David Cramer" <dcramer@broadjump.com>
>To: "Bob Stayton" <bobs@caldera.com>, "Matt G." <matt_g_@hotmail.com>,   
>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 


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 
    * DocBook tools support for XML namespaces (this generally comes for 
      with XSL, however I think support for W3C Schema Language is still 
    * The DocBook needs to be specified in a well-supported 
      schema language
    * DocBook documentation should be provided in a modular source format, 
      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 

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

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 

Matt Gruenke

MSN Photos is the easiest way to share and print your photos: 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC