DOCBOOK: Re: Modularity and PE reorganization

[Norman Walsh <ndw at nwalsh dot com>]

/ "Matt G." <matt_g_@hotmail.com> was heard to say:
| I think that's my point.  Where a given element has multiple meanings -
| particularly if the distinction is due to the term being used in
| unrelated topics - the best approach might be to add it to both sets.
| Of course, you'd want to be able to distinguish them, so you really
| want them to be separate elements - that falls out of namespace usage,
| nicely.

Do you have some specific examples in mind?

|>Moving to multiple namespaces isn't in the cards at the moment.
|
| Sure, but I'm not sure anything short of that will scale to address
| the needs and concerns of many involved in this discussion (and
| countless others).

I don't think namespaces would help very much in DocBook. There are
really only two sorts of ways to use them in a schema (let's imagine
we've moved beyond DTDs and we have full namespace support at our
disposal).

1. In the content model for "X", you allow "y:Z" to appear.

In this case, you have to explicitly name each element in the content
model where it occurs, and it can occur only where you place it. Using
namespaces here doesn't provide any functionality that you couldn't
achieve simply by using a different unqualified name for "Z".

If your argument is that there are subtle shades of meaning that could
be distinguished using namespaces, creating for example "x:literal"
and "y:literal" to distinguish between flavors of "literal", I'd need
a fair bit of convincing. If those two "literal"s are so different
that you want them to have different names, I suggest that they be
given...different names.

My intuition says that asking authors to distinguish between them on
the basis of namespace URI is way too obscure.

2. In the content model for "W", you allow "y:*" to appear.

This can be useful for mixing vocabularies, allowing SVG and MathML,
for example, but I don't think it fits into the design of a single
vocabulary very well.

I suppose one could put each "class" of elements in a different
namespace and simplify the content models by using this sort of
construct, but that would divide DocBook into something like 20
different namespaces. I don't think that's practical from any
perspective.

| My fear is that if DocBook doesn't continue to scale, it will stagnate
| and be replaced by something that does.  That would be mostly bad for
| most of us who have invested time and energy in learning, using,
| supporting, and enhancing docbook and its tools.

Certainly if DocBook fails to address the needs of its users, it will
be replaced. And given the amount of effort that we've put into it, I
think that would be disappointing. So we need to listen to our users
and adapt to suit their evolving needs.

But I have this feeling that DocBook has been successful in part
because it evolves *slowly*. It doesn't have a "flavor of the week".
Authors and publishers are by and large pragmatic, I think. They're in
this for the long haul.

I spend a lot of my life on the bleeding edge of XML technologies. I
think DocBook benefits from the fact that it hangs back a little,
where the water is deeper and the rapids (to mix metaphors) are less
violent.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Man's great misfortune is that he
http://www.oasis-open.org/docbook/ | has no organ, no kind of eyelid or
Chair, DocBook Technical Committee | brake, to mask or block a thought,
                                   | or all thought, when he wants
                                   | to.--Valéry