Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >>"Guy" == Guy Maor <[EMAIL PROTECTED]> writes:
> Guy> If standards can't be modified, how can they be improved? I think
> Guy> there is gain in allowing standards to be modified. Modified
> Guy> standards must be distributed with a prominent notice that this is not
> Guy> the original standard and that the original standard may be obtained
> Guy> from wherever.
Often, i.e., the TEI DTDs (a standard, and a DTD, like most DTDs), the
licensing on the standard says that the file name and the title of the
document must be changed if the standard is modified. So your SGML
Public Identifier would have to change too. This is sane and is
acceptable the DFSG AFAICT.
> Standards are modified by the standards body, not by any tom
> dick, or harry that comes along. How would things be if Debiian
> modifies the FHS, and so does Red Hat, and caldera an so. We all have
> our own FHS, and now none of the distributions are using compatible
> file layouts.
Well, suppose we want to add an appendix to the FHS. For instance,
the FHS doesn't not talk about icons and pixmaps and where shared
pixmaps should be placed. We should feel we have the power to add
components to the standard; in this case, probably it would mean a
separate *appendix* document. However, I could see cases where we
might feel that for the benefit of the developers, it's easier for
them to look at the FHS, and our extensions (still compliant with
baseline FHS) in the same document. So couldn't we, shouldn't we, be
empowered to retitle the document ("Filesystem Heirarchy Standard,
including Debian extensions"), and add a few additional directories,
in each case where we are adding, mark the addition as Debian-specific
very clearly?
> Like MS embracing java, and then extending it, and essentially
> breaking the write once, run anywhere promise of the standard.
Microsoft has a practice of not marking in their documentation that an
extension is MS-specific.
> A plethora of almost same bug subtly different "standards"
> dilutes the presence of the standard, and in my opinion, hurts the
> software community wirse than proprietary, non free software does. It
> divides us, and lowers the efficacy of the stnadardizing effort.
I agree, but I don't see why it is *necessarily* a problem if
annotated clearly, and if the derivation does not pose as the original
in any way.
> Guy> Translations should be encouraged also. Maybe "Translations and
> Guy> reformatting must be allowed with the stipulation that there is no
> Guy> loss of information." That might be too vague though.
>
> There is always a loss of information when translation
> occurs.
Well, Samuel Beckett used to translate his own works, written
originally in French, into English. Neither here nor there, since he
was the copyright holder.
> Guy> Why not? If I want to propose a new keyword in ANSI C and distribute
> Guy> a document called Guy's modified ANSI C, shouldn't I be allowed to?
>
> I would not like that to happen. Standards are made to enhance
> conformity, and allow entities to rely on external elements, secure
> in the belief that everything folllows a standard. Dilute that, and
> we all descend into chaos.
>
> Allowing this to happen is, in my opinion, as detrimental to
> our community as proprietary software.
I don't understand why you think this is so, *necessarily*.
DTDs are standards, as much as RFCs are. They state a standard
document structure, i.e., docbook. But if you look at Norman Walsh
and how he setup the modular DTDs and stylesheets, it is possible, nay
even encouraged, that document engineers are able to add non-standard
extensions to the standard. Now these don't pose as being baseline
Docbook, nor do extensions break existing, pure docbook-compliant
document instances.
Remember that standards always *trail* real-world practice as a matter
of course. Generally, it is thru the practice and implementation of
new functionality do new standards arise.
Perhap's Guy's "technical vs non-technical" distinction would help
here, though I find it difficult to conceive that we can define these
terms in sufficient granularity for a new DFSG.
Marcus's discussions about standards were adequate, I think, while
still protecting the integrity of the standards.
--
.....A. P. [EMAIL PROTECTED]<URL:http://www.onShore.com/>
