CDR - The Common Lisp Document Repository
What?
The Common Lisp Document Repository is a repository of documents that
are of interest to the Common Lisp community. The most important
property of a CDR document is that it will never change: if you refer to
it, you can be sure that your reference will always refer to exactly the
same document.
Why?
There have been a number of attempts to establish a standardization
process for Common Lisp after it has been officially published as an
ANSI standard. The ANSI standardization was very costly and very time
consuming (according to
http://groups.google.com/group/comp.lang.lisp/msg/15248a1b11c5a603 it
took nearly 10 years and at least $400K).
The goal of the Common Lisp Document Repository is to be more
light-weight and more efficient. We focus on one aspect of
standardization: the ability to refer to a specification document in an
unambiguous way.
The Common Lisp Document Repository intentionally does not define a
process for coming up with specifications or any other means to
guarantee some level of quality of the submitted documents. Instead, we
aim for a community-driven, decentralized approach to come up, discuss
and finalize specifications. In this sense, we only provide the services
of librarians.
We hope that the Common Lisp Document Repository has the potential to
prove useful in establishing new de-facto standards, and to serve as a
stepping stone for more formal standardizations in the long run.
Where?
The Common Lisp Document Repository is hosted at http://cdr.eurolisp.org
How?
The Common Lisp Document Repository is a repository of printable text
documents that contain material that are of interest to the Common Lisp
community. For example, a CDR document can contain specifications of
libraries, language extensions, example implementations, test suites,
articles, etc. Each CDR document will be identified by a number. Form
and possible contents of CDR documents are not prescribed, but the goal
is to provide the Common Lisp community with a way to unambiguously
refer to a document by way of mentioning its CDR number.
The repository already contains two CDR documents: CDR 0 describes CDR
itself, and CDR 1 is the CLOS Metaobject Protocol specification as
published in the book "The Art of the Metaobject" by Gregor Kiczales,
Jim des Rivieres and Daniel G. Bobrow.
The presence of a document in the CDR repository does not imply a
recommendation of any kind, but we leave the acceptance or rejection of
particular documents to the community's natural selection process. We
expect that some CDR documents will claim to be replacements of, or
clarifications for, previous ones, but again such statements do not mean
that this repository's goal is to enforce such developments. We are just
librarians who want to make it possible to refer and cite documents of
interest to Common Lispers.
We use a light-weight process that consists of the following steps:
1. One or more authors submit a document.
2. We check that the document is a printable text document, that it
is indeed about Common Lisp, and that it does not contain objectionable
material (like porn, religious or political statements, etc.).
3. The document will be immediately assigned a fresh CDR number that
can be used to refer to the document. We will make the document
available for an initial period, after which it will be frozen and moved
into final status, unless the authors decide to withdraw the document
during the initial period.
For more details about the process, see the CDR manual at
http://cdr.eurolisp.org
The CDR editors
Marc Battyani, Pascal Costanza, Arthur Lemmens, Edi Weitz
If you're archiving CDR documents what happens to CAR documents?
hooray stupid puns
Kyle
Pascal Costanza wrote:
> CDR - The Common Lisp Document Repository
>
> What?
>
> The Common Lisp Document Repository is a repository of documents that
> are of interest to the Common Lisp community. The most important
> property of a CDR document is that it will never change: if you refer to
> it, you can be sure that your reference will always refer to exactly the
> same document.
>
> Why?
>
> There have been a number of attempts to establish a standardization
> process for Common Lisp after it has been officially published as an
> ANSI standard. The ANSI standardization was very costly and very time
> consuming (according to
> http://groups.google.com/group/comp.lang.lisp/msg/15248a1b11c5a603 it
> took nearly 10 years and at least $400K).
>
> The goal of the Common Lisp Document Repository is to be more
> light-weight and more efficient. We focus on one aspect of
> standardization: the ability to refer to a specification document in an
> unambiguous way.
>
> The Common Lisp Document Repository intentionally does not define a
> process for coming up with specifications or any other means to
> guarantee some level of quality of the submitted documents. Instead, we
> aim for a community-driven, decentralized approach to come up, discuss
> and finalize specifications. In this sense, we only provide the services
> of librarians.
>
> We hope that the Common Lisp Document Repository has the potential to
> prove useful in establishing new de-facto standards, and to serve as a
> stepping stone for more formal standardizations in the long run.
>
> Where?
>
> The Common Lisp Document Repository is hosted at http://cdr.eurolisp.org
>
> How?
>
> The Common Lisp Document Repository is a repository of printable text
> documents that contain material that are of interest to the Common Lisp
> community. For example, a CDR document can contain specifications of
> libraries, language extensions, example implementations, test suites,
> articles, etc. Each CDR document will be identified by a number. Form
> and possible contents of CDR documents are not prescribed, but the goal
> is to provide the Common Lisp community with a way to unambiguously
> refer to a document by way of mentioning its CDR number.
>
> The repository already contains two CDR documents: CDR 0 describes CDR
> itself, and CDR 1 is the CLOS Metaobject Protocol specification as
> published in the book "The Art of the Metaobject" by Gregor Kiczales,
> Jim des Rivieres and Daniel G. Bobrow.
>
> The presence of a document in the CDR repository does not imply a
> recommendation of any kind, but we leave the acceptance or rejection of
> particular documents to the community's natural selection process. We
> expect that some CDR documents will claim to be replacements of, or
> clarifications for, previous ones, but again such statements do not mean
> that this repository's goal is to enforce such developments. We are just
> librarians who want to make it possible to refer and cite documents of
> interest to Common Lispers.
>
> We use a light-weight process that consists of the following steps:
>
> 1. One or more authors submit a document.
> 2. We check that the document is a printable text document, that it
> is indeed about Common Lisp, and that it does not contain objectionable
> material (like porn, religious or political statements, etc.).
> 3. The document will be immediately assigned a fresh CDR number that
> can be used to refer to the document. We will make the document
> available for an initial period, after which it will be frozen and moved
> into final status, unless the authors decide to withdraw the document
> during the initial period.
>
> For more details about the process, see the CDR manual at
> http://cdr.eurolisp.org
>
>
> The CDR editors
> Marc Battyani, Pascal Costanza, Arthur Lemmens, Edi Weitz
·······@gmail.com wrote:
> If you're archiving CDR documents what happens to CAR documents?
>
It's not a good idea to archive CAR documents because you need them when
you drive.
> hooray stupid puns
Yay! ;)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> wrote:
+---------------
| CDR - The Common Lisp Document Repository
...
| Each CDR document will be identified by a number. Form and
| possible contents of CDR documents are not prescribed, but the goal
| is to provide the Common Lisp community with a way to unambiguously
| refer to a document by way of mentioning its CDR number.
+---------------
How does this differ from what has been referred to for the last
several years as CLRFIs? [Note: This is not an criticism, but a
simple request for information/elaboration/clarification...]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Pascal Costanza <··@p-cos.net> wrote:
> +---------------
> | CDR - The Common Lisp Document Repository
> ...
> | Each CDR document will be identified by a number. Form and
> | possible contents of CDR documents are not prescribed, but the goal
> | is to provide the Common Lisp community with a way to unambiguously
> | refer to a document by way of mentioning its CDR number.
> +---------------
>
> How does this differ from what has been referred to for the last
> several years as CLRFIs? [Note: This is not an criticism, but a
> simple request for information/elaboration/clarification...]
We haven't specifically modeled CDR after CLRFI, and haven't taken a
look at CLRFI when we formulated the CDR "process". However, there are
surely similarities.
The main difference, as I see it, is that CDR is stripped down to the
barest essentials: there is no process defined for discussing concrete
CDR documents, we don't provide mailing lists, we don't prescribe how a
mailing list should be used and we don't prescribe the structure of a
CDR document. All we provide is a reference to a document - a CDR number
- and the guarantee that a document will not change, so that referring
to a CDR document will be unambiguous. We also don't endorse the use of
any CDR document, although of course we hope that CDR documents will
come up that are deemed so useful that they will be widely implemented.
The goal of CDR's minimalist approach is that more documents can be
accepted in a shorter amount of time. The fact that we don't do any
quality assurance is important here: Even if it happens that we as CDR
editors simply don't know enough about the matter of a concrete CDR
document so that we effectively cannot judge the material, we can still
accept it because there is no element in the CDR "process" that would
hinder the acceptance of such a document.
There is, of course, some minimal "process" involved. We hope that it
will be tested soon with concrete CDR submissions.
Pascal
P.S.: We don't want to discourage a more formal process in the long run.
At some stage, more binding standards / recommendations may be necessary
again. CDR documents could be a first step in that direction. In the
meantime, we hope that CDR is an sufficient improvement over the current
situation.
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Rob Warnock wrote:
> > Pascal Costanza <··@p-cos.net> wrote:
> > +---------------
> > | CDR - The Common Lisp Document Repository
> > ...
> > | Each CDR document will be identified by a number. Form and
> > | possible contents of CDR documents are not prescribed, but the goal
> > | is to provide the Common Lisp community with a way to unambiguously
> > | refer to a document by way of mentioning its CDR number.
> > +---------------
> >
> > How does this differ from what has been referred to for the last
> > several years as CLRFIs? [Note: This is not an criticism, but a
> > simple request for information/elaboration/clarification...]
>
> We haven't specifically modeled CDR after CLRFI, and haven't taken a
> look at CLRFI when we formulated the CDR "process". However, there are
> surely similarities.
It would be good to put the first two CLRFI submissions on CDR too.
"Rob Thorpe" <·············@antenova.com> writes:
> Pascal Costanza wrote:
> > We haven't specifically modeled CDR after CLRFI, and haven't taken
> > a look at CLRFI when we formulated the CDR "process". However,
> > there are surely similarities.
> It would be good to put the first two CLRFI submissions on CDR too.
I guess the first one was more useful as a CLRFI test case than in
real life.
There would be a certain elegance to having CDR 2 be equal to CLRFI 2.
Lars Brinkhoff wrote:
> "Rob Thorpe" <·············@antenova.com> writes:
>> Pascal Costanza wrote:
>>> We haven't specifically modeled CDR after CLRFI, and haven't taken
>>> a look at CLRFI when we formulated the CDR "process". However,
>>> there are surely similarities.
>> It would be good to put the first two CLRFI submissions on CDR too.
>
> I guess the first one was more useful as a CLRFI test case than in
> real life.
>
> There would be a certain elegance to having CDR 2 be equal to CLRFI 2.
We, the CDR editors, don't know CLRFI 2 well enough to want to take the
responsibility to submit it as a CDR 2. We would welcome such a
submission, though.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Le Thu, 10 Aug 2006 13:55:04 +0200, Pascal Costanza a écrit :
> The Common Lisp Document Repository intentionally does not define a
> process for coming up with specifications or any other means to
> guarantee some level of quality of the submitted documents.
I'm pretty sure this is the strongest basis for an unsuccesful
standardization process.
You *have* to discuss and settle the submission process, even if it's a
bit informal. And without some quality guidelines, odds are great that
CDR will be filled up with crappy documents, which would surely lead to
thinking that CDR is crappy as a whole, even if it in fact contains a
bunch of high-quality documents that the entire community discussed and
refined.
Take Boost for C++, SRFI for Scheme, JEPs for Jabber. They all brought
up a process and/or QA to be useful. I'm sure this is absolutely needed.
To be clear, I don't think it has to be a heavy-weight multi-layer
blind-review i-don't-know-else formal process with automated
qualification of submissions. But clear and enforced guidelines on
submission and some rules for the acceptance of documents would greatly
help raise the quality.
> Instead, we aim for a community-driven, decentralized approach to come
> up, discuss and finalize specifications. In this sense, we only
> provide the services of librarians.
Go to your nearest library: is it in any way a coherent set of useful
documents? Not any library or bookshop that I ever visited was.
But hey, I'm no standard guru, and I did never attend standardization
processes in my life, so hopefully you'll prove me wrong.
Doubtfully,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
Pierre THIERRY wrote:
> Le Thu, 10 Aug 2006 13:55:04 +0200, Pascal Costanza a écrit :
> > The Common Lisp Document Repository intentionally does not define a
> > process for coming up with specifications or any other means to
> > guarantee some level of quality of the submitted documents.
>
> I'm pretty sure this is the strongest basis for an unsuccesful
> standardization process.
>
> You *have* to discuss and settle the submission process, even if it's a
> bit informal.
When skimming the site, I got the impression this was meant to serve as
part of a standardization process; mutually nonexclusive layers could
be built on top by others. From an engineering standpoint, this seems
like a sound attempt, whether or not it succeeds. All they're doing is
assigning unique numbers to documents, with some minimal intervention,
so these documents may be reliably referenced in communication.
(And as we see with Common Lisp, its "success" may be entirely
unpredictable and time-varying.)
But perhaps I got the wrong impression.
Tayssir
Pierre THIERRY wrote:
> Le Thu, 10 Aug 2006 13:55:04 +0200, Pascal Costanza a écrit :
>> The Common Lisp Document Repository intentionally does not define a
>> process for coming up with specifications or any other means to
>> guarantee some level of quality of the submitted documents.
>
> I'm pretty sure this is the strongest basis for an unsuccesful
> standardization process.
I'm pretty sure that it's not.
> You *have* to discuss and settle the submission process, even if it's a
> bit informal. And without some quality guidelines, odds are great that
> CDR will be filled up with crappy documents, which would surely lead to
> thinking that CDR is crappy as a whole, even if it in fact contains a
> bunch of high-quality documents that the entire community discussed and
> refined.
CDR will be filled with crappy documents only if lots of crappy
documents will be submitted. I am not aware of a process that would help
to avoid that problem. There are much more formal processes elsewhere
which also contain lots of questionable specifications. It's a myth that
a process guarantees anything. (That's not completely unlike software
development processes.)
> Take Boost for C++, SRFI for Scheme, JEPs for Jabber. They all brought
> up a process and/or QA to be useful. I'm sure this is absolutely needed.
>
> To be clear, I don't think it has to be a heavy-weight multi-layer
> blind-review i-don't-know-else formal process with automated
> qualification of submissions. But clear and enforced guidelines on
> submission and some rules for the acceptance of documents would greatly
> help raise the quality.
We encourage submitters to publicly discuss their documents before they
submit them. Nowadays, it is pretty straightforward to arrange for
public discussions in one way or the other. You can, among other things,
discuss proposals in newsgroups, like comp.lang.lisp or the currently
underutilized comp.lang.clos, in mailing lists that you set up yourself
at common-lisp.net or as a Yahoo group, on Wikis like cliki.net or the
ALU wiki, etc. It's also possible that a group of people meets at some
venue, like a Lisp Conference or Workshop or the Libre Software Meeting,
discusses the basics of a proposal and then one or two people work out
the details on their own. There are probably lots of other ways.
Since there are so many ways to discuss and work on specifications, and
since we don't believe that one size fits all, we don't want to
prescribe anything in this regard. To the contrary, we believe that
people should use the most appropriate "process" for the document at hand.
We believe that the Common Lisp mainly consists of intelligent people
who know what they are doing. It is recognized that there should be a
way to be able to refer to new specifications / standards so that users
and vendors have a common ground. That's exactly what we would like to
provide. Apart from that we want to stay out of the way and let everyone
work in the way they see fit.
>> Instead, we aim for a community-driven, decentralized approach to come
>> up, discuss and finalize specifications. In this sense, we only
>> provide the services of librarians.
>
> Go to your nearest library: is it in any way a coherent set of useful
> documents? Not any library or bookshop that I ever visited was.
...even though they probably tried...
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Le Fri, 11 Aug 2006 10:42:19 +0200, Pascal Costanza a écrit :
> CDR will be filled with crappy documents only if lots of crappy
> documents will be submitted. I am not aware of a process that would
> help to avoid that problem.
Of course, all standard bodies endorse a vast amount of crappy
standards. But QA helps by being somewith like a low-pass filter. In
Boost, for example, no library comes with only a reference
implementation and no real documentation. Sometimes the documentation is
not really useful because too targeted toward the implementation notes
and not enough toward the user of the library, but not publishing a
library without any documentation is a (great) first step toward overall
quality.
> There are much more formal processes elsewhere which also contain lots
> of questionable specifications. It's a myth that a process guarantees
> anything. (That's not completely unlike software development
> processes.)
I agree it's like software development. Like in any process, some rules
help, but too many rules get in the way.
> We believe that the Common Lisp mainly consists of intelligent people
> who know what they are doing.
It's true that the kind and size of the community could help making CDR
documentation successful... Not sure it will scale if Lisp get hype in
the next years, then! ;-)
Quickly,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
Pierre THIERRY wrote:
> Le Fri, 11 Aug 2006 10:42:19 +0200, Pascal Costanza a écrit :
>> CDR will be filled with crappy documents only if lots of crappy
>> documents will be submitted. I am not aware of a process that would
>> help to avoid that problem.
>
> Of course, all standard bodies endorse a vast amount of crappy
> standards. But QA helps by being somewith like a low-pass filter. In
> Boost, for example, no library comes with only a reference
> implementation and no real documentation. Sometimes the documentation is
> not really useful because too targeted toward the implementation notes
> and not enough toward the user of the library, but not publishing a
> library without any documentation is a (great) first step toward overall
> quality.
>
>> There are much more formal processes elsewhere which also contain lots
>> of questionable specifications. It's a myth that a process guarantees
>> anything. (That's not completely unlike software development
>> processes.)
>
> I agree it's like software development. Like in any process, some rules
> help, but too many rules get in the way.
More importantly, it's unclear which rules help and which don't. The
mere presence of rules doesn't ensure anything, and sometimes rules have
unintended side effects that may even counter the original intention.
There are plenty of examples for this effect.
Therefore, we have set up as few rules as possible, so that they don't
stand in the way of actual submissions of CDR documents. After the first
100 CDRs, or so, we can then reevaluate whether the result meets a
sufficiently high standard or whether there is a need for improvement. ;)
>> We believe that the Common Lisp mainly consists of intelligent people
>> who know what they are doing.
>
> It's true that the kind and size of the community could help making CDR
> documentation successful... Not sure it will scale if Lisp get hype in
> the next years, then! ;-)
Again, these and other problems can be addressed as soon as they occur. ;)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Pierre THIERRY wrote:
>> Le Thu, 10 Aug 2006 13:55:04 +0200, Pascal Costanza a écrit :
>>> The Common Lisp Document Repository intentionally does not define a
>>> process for coming up with specifications or any other means to
>>> guarantee some level of quality of the submitted documents.
>>
>> I'm pretty sure this is the strongest basis for an unsuccesful
>> standardization process.
>
> I'm pretty sure that it's not.
>
>> You *have* to discuss and settle the submission process, even if it's a
>> bit informal. And without some quality guidelines, odds are great that
>> CDR will be filled up with crappy documents, which would surely lead to
>> thinking that CDR is crappy as a whole, even if it in fact contains a
>> bunch of high-quality documents that the entire community discussed and
>> refined.
>
> CDR will be filled with crappy documents only if lots of crappy
> documents will be submitted. I am not aware of a process that would
> help to avoid that problem. There are much more formal processes
> elsewhere which also contain lots of questionable specifications. It's
> a myth that a process guarantees anything. (That's not completely
> unlike software development processes.)
>
>> Take Boost for C++, SRFI for Scheme, JEPs for Jabber. They all brought
>> up a process and/or QA to be useful. I'm sure this is absolutely needed.
>>
>> To be clear, I don't think it has to be a heavy-weight multi-layer
>> blind-review i-don't-know-else formal process with automated
>> qualification of submissions. But clear and enforced guidelines on
>> submission and some rules for the acceptance of documents would greatly
>> help raise the quality.
>
> We encourage submitters to publicly discuss their documents before
> they submit them. Nowadays, it is pretty straightforward to arrange
> for public discussions in one way or the other. You can, among other
> things, discuss proposals in newsgroups, like comp.lang.lisp or the
> currently underutilized comp.lang.clos, in mailing lists that you set
> up yourself at common-lisp.net or as a Yahoo group, on Wikis like
> cliki.net or the ALU wiki, etc. It's also possible that a group of
> people meets at some venue, like a Lisp Conference or Workshop or the
> Libre Software Meeting, discusses the basics of a proposal and then
> one or two people work out the details on their own. There are
> probably lots of other ways.
>
> Since there are so many ways to discuss and work on specifications,
> and since we don't believe that one size fits all, we don't want to
> prescribe anything in this regard. To the contrary, we believe that
> people should use the most appropriate "process" for the document at
> hand.
>
> We believe that the Common Lisp mainly consists of intelligent people
> who know what they are doing. It is recognized that there should be a
> way to be able to refer to new specifications / standards so that
> users and vendors have a common ground. That's exactly what we would
> like to provide. Apart from that we want to stay out of the way and
> let everyone work in the way they see fit.
>
>>> Instead, we aim for a community-driven, decentralized approach to come
>>> up, discuss and finalize specifications. In this sense, we only
>>> provide the services of librarians.
>>
>> Go to your nearest library: is it in any way a coherent set of useful
>> documents? Not any library or bookshop that I ever visited was.
>
> ...even though they probably tried...
>
Although I can understand nowhere man's argument, I think the
minimalist approach fits well with the aims for a community driven
effort.
The problem with any formal process to judge eligible articles is that
it will be down to the interpretation of those doing the evaluation
and we could end up with a repository that only reflects the beliefs
and values of the group that do this evaluation.
I'm wondering if it could be done more like some libraries I've used.
As space becomes a premium, it becomes necessary to remove some books.
The method used is to select books which have not been borrowed for
the longest period, publicise the list and see if anyone has any
strong argument why the book should not be removed.
This approach does have one significant drawback. Sometimes, new ideas
come out of an old idea which never successfully took off. I can think
of a couple of instances in computing science when someone has
re-visited an old idea and given it new life due to a new
interpretation based on more recent developments in both understanding
and hardware capabilities. It is likely books containing ideas which
have never gained wide acceptance also have low borrowing rates and
therefore wold be candidates for removal, possibly resulting in the
loss of a good idea which may have simply been "before its time".
However, this is probably less of a negative than having a repository
that is smaller and only contains articles which the review process
found acceptable - in fact, the good idea before its time probably
wold never get into such a repository anyway.
So, maybe the way to go might be to track downloads of articles and
if/when numbers/size become an issue, a spring cleaning could remove
those articles which nobody reads/downloads.
One question, can articles only be submitted by the author or can
anyone submit an article they believe is worth putting in the
repository? I'm just wondering about how we build up the historical
aspects of a common lisp document repository.
Tim
--
tcross (at) rapttech dot com dot au
Tim X wrote:
> One question, can articles only be submitted by the author or can
> anyone submit an article they believe is worth putting in the
> repository? I'm just wondering about how we build up the historical
> aspects of a common lisp document repository.
>
Well, given that CDR #1 appears to be the MOP, and was submitted
by Pascal C. rather than Gregor K &co., I'm guessing that decision's
already made. :-)
Tim X wrote:
> I'm wondering if it could be done more like some libraries I've used.
> As space becomes a premium, it becomes necessary to remove some books.
> The method used is to select books which have not been borrowed for
> the longest period, publicise the list and see if anyone has any
> strong argument why the book should not be removed.
Fortunately, space rarely becomes an issue on the net.
> This approach does have one significant drawback. Sometimes, new ideas
> come out of an old idea which never successfully took off. I can think
> of a couple of instances in computing science when someone has
> re-visited an old idea and given it new life due to a new
> interpretation based on more recent developments in both understanding
> and hardware capabilities. It is likely books containing ideas which
> have never gained wide acceptance also have low borrowing rates and
> therefore wold be candidates for removal, possibly resulting in the
> loss of a good idea which may have simply been "before its time".
>
> However, this is probably less of a negative than having a repository
> that is smaller and only contains articles which the review process
> found acceptable - in fact, the good idea before its time probably
> wold never get into such a repository anyway.
>
> So, maybe the way to go might be to track downloads of articles and
> if/when numbers/size become an issue, a spring cleaning could remove
> those articles which nobody reads/downloads.
We will think about these problems when they occur. There are probably
several possible solutions, and we should choose the most appropriate
one at that stage in the future.
> One question, can articles only be submitted by the author or can
> anyone submit an article they believe is worth putting in the
> repository? I'm just wondering about how we build up the historical
> aspects of a common lisp document repository.
Anyone can submit anything. Of course, you should make sure that you
have the necessary (copy)rights to submit a document. When in doubt,
please contact us and we can try to resolve problems. Of course, the
easiest is to contact the authors of the respective documents directly.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pierre THIERRY <···········@levallois.eu.org> writes:
> You *have* to discuss and settle the submission process, even if it's a
> bit informal. And without some quality guidelines, odds are great that
> CDR will be filled up with crappy documents, which would surely lead to
This is unlikely. When it comes to actually doing rather than
talking, Lispers do not seem terribly active, so I don't expect the
CDR to be flooded, with crappy documents or otherwise, anytime soon.
If it works, it will contain mostly documents submitted by those who
know what they are doing.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Pierre THIERRY wrote:
> Le Thu, 10 Aug 2006 13:55:04 +0200, Pascal Costanza a �crit�:
>> The Common Lisp Document Repository intentionally does not define a
>> process for coming up with specifications or any other means to
>> guarantee some level of quality of the submitted documents.
>
> I'm pretty sure this is the strongest basis for an unsuccesful
> standardization process.
>
Meh. Could view it as just separation of concerns, leaving the
standardisation process to someone else, blessing certain CDRs
into standards (or having CDRs that are meta-CDRs, like RFCs
that say "comply with all these earlier RFCs and you're compliant
with this RFC").
What would most concern me would be replicability.
As far as I can see in a cursory examination, the CDR repository does
NOT require general redistributability of copies of documents in the CDR
collection, only that the CDR maintainers be able to redistribute. This
looks like a deliberate choice, of course, it's just one I don't
personally particularly like for a body of documents intend to be
community standards.
At least one could have a clearly delineated Completely Allowed
Redistribution "CAR CDR" (sorry, sorry) subset of the CDR? Ideally as
far as I can see it, CAR-CDR documents would all be under a single,
clear and uniform "nearly public domain" license. Maybe just a BSD
documentation license with appropriate string substitutions.
http://en.wikipedia.org/wiki/FreeBSD_Documentation_License
Maybe I should quit whining and edit this post into a CDR submission, so
that subsequent CDR submissions could claim to be CAR (CDR #N)
compliant, and after appropriate verification (which would be
essenmtially the same as the normal license verification required by
the CDR maintainers _anyway_, so a submission purporting to be CAR CDR
but not actually so would fail the submission process _anyway_), they
would presumably be so.
*Just because other people have and redistribute copies, even modified
ones, of the CDR or at least CAR-CDR subset, doesn't mean that the CDR
maintainers couldn't sign their copy with a private key, and thus
maintain canonical status - as long as the community considers
documents from a source that signs with maintainer key XYZZY (with
appropriate wrinkles for periodic new key pairs) as canonical, they are
The Ones. At least unless/until quantum computing royally screws up
everything crypto related.
While we're at it, can I ask that CDR maintainers generate checksums and
sign CDR publications with such a maintainer key if they're not already
doing so? Regardless of legalities, it'd be sensible.
David Golden wrote:
> Pierre THIERRY wrote:
>
>> Le Thu, 10 Aug 2006 13:55:04 +0200, Pascal Costanza a �crit :
>>> The Common Lisp Document Repository intentionally does not define a
>>> process for coming up with specifications or any other means to
>>> guarantee some level of quality of the submitted documents.
>> I'm pretty sure this is the strongest basis for an unsuccesful
>> standardization process.
>>
>
> Meh. Could view it as just separation of concerns, leaving the
> standardisation process to someone else, blessing certain CDRs
> into standards (or having CDRs that are meta-CDRs, like RFCs
> that say "comply with all these earlier RFCs and you're compliant
> with this RFC").
>
> What would most concern me would be replicability.
> As far as I can see in a cursory examination, the CDR repository does
> NOT require general redistributability of copies of documents in the CDR
> collection, only that the CDR maintainers be able to redistribute. This
> looks like a deliberate choice, of course, it's just one I don't
> personally particularly like for a body of documents intend to be
> community standards.
It is deliberate. We want to require as little as possible from a CDR
document, but it's evident that at least we need the right to publish a
CDR document. It's straightforward to attach a license to a CDR document
that ensures that it can be redistributed freely - there are plenty of
licenses that you can choose from, and the use of such licenses is
actually what we would prefer. But again: we would like to set the
barriers as low as possible.
> At least one could have a clearly delineated Completely Allowed
> Redistribution "CAR CDR" (sorry, sorry) subset of the CDR? Ideally as
> far as I can see it, CAR-CDR documents would all be under a single,
> clear and uniform "nearly public domain" license. Maybe just a BSD
> documentation license with appropriate string substitutions.
> http://en.wikipedia.org/wiki/FreeBSD_Documentation_License
>
> Maybe I should quit whining and edit this post into a CDR submission, so
> that subsequent CDR submissions could claim to be CAR (CDR #N)
> compliant, and after appropriate verification (which would be
> essenmtially the same as the normal license verification required by
> the CDR maintainers _anyway_, so a submission purporting to be CAR CDR
> but not actually so would fail the submission process _anyway_), they
> would presumably be so.
>
>
> *Just because other people have and redistribute copies, even modified
> ones, of the CDR or at least CAR-CDR subset, doesn't mean that the CDR
> maintainers couldn't sign their copy with a private key, and thus
> maintain canonical status - as long as the community considers
> documents from a source that signs with maintainer key XYZZY (with
> appropriate wrinkles for periodic new key pairs) as canonical, they are
> The Ones. At least unless/until quantum computing royally screws up
> everything crypto related.
>
> While we're at it, can I ask that CDR maintainers generate checksums and
> sign CDR publications with such a maintainer key if they're not already
> doing so? Regardless of legalities, it'd be sensible.
It was our explicit goal to avoid any over-engineering of the CDR
submission "process," and my fear would be that your suggestion would
lead to the kind of overhead that we wanted to avoid. I don't want to
discourage you to submit such a proposal if you regard it as an
essential contribution, but I would also like to encourage you to
consider whether working on a proposal that directly improves Common
Lisp isn't actually a more worthwhile effort.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> It was our explicit goal to avoid any over-engineering of the CDR
> submission "process," and my fear would be that your suggestion would
> lead to the kind of overhead that we wanted to avoid.
Refering to CDR signing their publications, or to my vaguer desire for a
pseudostandardised free license for the docs?
Regarding the former - digitally signing publications is not exactly
hard work (except for your CPU for a few moments :-) ). It's not
something that needs to be done at a hifalutin' level, it's basically
a one-liner by a CDR maintainer prior to upload.
Just in case: One might or might not also ask submitters to digitally
sign submissions, I guess, as part of your process for CDR submissions,
but that's not what I was concerned about (and would indeed constitute
more of a barrier), I was hoping that CDR would just sign *their*
*publications* of the documents. No additional burden for submitters,
minor additional burden for CDR maintainers (that could well pay off
anyway in the event of a major disaster-recovery scenario).
David Golden wrote:
> Pascal Costanza wrote:
>
>> It was our explicit goal to avoid any over-engineering of the CDR
>> submission "process," and my fear would be that your suggestion would
>> lead to the kind of overhead that we wanted to avoid.
>
> Refering to CDR signing their publications, or to my vaguer desire for a
> pseudostandardised free license for the docs?
Both.
> Regarding the former - digitally signing publications is not exactly
> hard work (except for your CPU for a few moments :-) ). It's not
> something that needs to be done at a hifalutin' level, it's basically
> a one-liner by a CDR maintainer prior to upload.
I don't see what problem this would solve, and _if_ it doesn't solve a
problem, then it's unnecessary overhead. (There will be several
"one-liners" to take care of, and unfortunately they add up. ;)
So what problem do you think this would solve?
> Just in case: One might or might not also ask submitters to digitally
> sign submissions, I guess, as part of your process for CDR submissions,
> but that's not what I was concerned about (and would indeed constitute
> more of a barrier), I was hoping that CDR would just sign *their*
> *publications* of the documents. No additional burden for submitters,
> minor additional burden for CDR maintainers (that could well pay off
> anyway in the event of a major disaster-recovery scenario).
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Le Sat, 12 Aug 2006 14:02:14 +0100, David Golden a écrit :
>>> The Common Lisp Document Repository intentionally does not define a
>>> process for coming up with specifications or any other means to
>>> guarantee some level of quality of the submitted documents.
>> I'm pretty sure this is the strongest basis for an unsuccesful
>> standardization process.
> Meh. Could view it as just separation of concerns,
Yeah, Tayssir post made me realize that. CDR is maybe a very good
primitive set of instructions for a high-level standard system...
I'm probably over-engineering here. My C++ side. ;-)
Quickly,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
Le Sat, 12 Aug 2006 14:02:14 +0100, David Golden a écrit :
> At least one could have a clearly delineated Completely Allowed
> Redistribution "CAR CDR" (sorry, sorry) subset of the CDR? Ideally
> as far as I can see it, CAR-CDR documents would all be under a single,
> clear and uniform "nearly public domain" license. Maybe just a BSD
> documentation license with appropriate string substitutions.
Part of the usefulness of a free document, as for free software, is
availibility of the source code.
Is there a way to submit a document to CDR along with it's source code
and/or alternate formats?
Curiously,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
Pierre THIERRY wrote:
> Le Sat, 12 Aug 2006 14:02:14 +0100, David Golden a écrit :
>> At least one could have a clearly delineated Completely Allowed
>> Redistribution "CAR CDR" (sorry, sorry) subset of the CDR? Ideally
>> as far as I can see it, CAR-CDR documents would all be under a single,
>> clear and uniform "nearly public domain" license. Maybe just a BSD
>> documentation license with appropriate string substitutions.
>
> Part of the usefulness of a free document, as for free software, is
> availibility of the source code.
>
> Is there a way to submit a document to CDR along with it's source code
> and/or alternate formats?
That's mostly up to you. You may choose to make source code part of the
submitted document, for example as an appendix, or provide it as what we
call "accompanying material." Accompanying material can, for example, be
archives of mailing lists that have led to the submitted document,
source code, presentation slides, etc. It largely depends on what you
consider essential and inessential parts of a submitted document. For
example, you can submit source code to nail the specification of some
functionality, or you can submit it to illustrate the use of some
library. The former should probably be part of the proper document, and
the latter part of accompanying material (although it could also be the
other way around in other cases, who knows ;).
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/