Re: Re^4: some suggestions for docreg
Marco.Budde@hqsys.antar.com (Marco Budde) writes:
> Am 02.05.98 schrieb apharris # burrito.onshore.com ...
>
> APH> A single document ID may have multiple formats and
> APH> multiple languages,
>
> I disagree. This will not work, because each language needs its own title
> and abstract. If I install for example the German PPP HOWTO I don#t want
> an abstract in English but in German.
That's a technical problem and has technical solutions. Say we have a
local knob for the local sysadmin saying "do prefer German
documentation". Then a format could provide a translation of the
section and the abstract. Perhaps when both English and German are
available, German is presented instead.
Anyhow this little technical niggle can be solved without
necessitating several divergant document ids. After all, the document
is the same document, deep down, so it should have one document id.
The point is that we have identified the two primary entities,
documents and formats of documents, we have identified their
relationship (many to one). These entities have a pretty strong
real-world representation. We must stick to these abstractions unless
there's a *real* *good* reason to break them. This is not such a
reason.
Consider if we had 7 different transations of the SCSI FAQ, all as
different entities; how could we manage them as one document per se?
We couldn't. So we're diluting the operative power of our own
abstractions.
This is a fundamental data modeling principle. And our documentation
standard is fundamentally a data modeling exercise: how to model real
world documentation. The DDH, for instance, should be seen as a
domain specification, where our particular domain is a nested tree.
The operative issues there are whether documents need to be
*constrained* to the domain or whether the domain may be extended in
certain situations. My view is that the domain ought to be
constrained but that a document may also be able to define a "scope"
(i.e., gcc) which is a leaf on the DDH node tree.
Marco, over and over again you seem to lose sight of the operative
abstractions. Please try to keep those abstractions at the front of
your mind and forget the technical issues for now. I believe in
strong abstractions first, code later; I also believe in keeping it
simple.
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: