CLJ newsgroup FAQ

D

Dr John Stockton

kelvlam said:
Sorry I haven't read through the FAQ. I will do so now.


The newsgroup FAQ has not been posted here for some considerable while.

The latest version I know of is 8.1 - 2005-11-05
but I think the Web site serves 8.0 - 2004-03-15

We cannot expect new readers, especially those entering via Web pages,
to know of the FAQ without a regular posting of something with a
suitable Subject, whether it be a FAQ or a FAQ pointer - and the Subject
must be such as they will understand ("Quick Answers" is OK; IMHO "META"
is not).


As far as I know, the existing technical content is correct; but the FAQ
could IMHO be improved by re-wording here and there. I don't know how
many <FAQENTRY> items remain outstanding.


Is it time for someone else, someone who (unlike me) has access to a
system which can post regularly, to take over the FAQ? ISTM that those
from smaller countries in mainland Europe, having been taught properly,
seem to write good straightforward clear English.
 
M

Matt Kruse

Dr said:
ISTM that
those from smaller countries in mainland Europe, having been taught
properly, seem to write good straightforward clear English.

Your xenophobia is so blatant as to be amusing.

Do those from smaller countries in mainland Europe, having been taught to be
snobbish and elitist, also seem to write sentences using absurdly dense
abbreviations, references to obfuscated url's in signatures, and web pages
so bland and ugly as to be unreadable?
Just curious!
 
R

Randy Webb

Dr John Stockton said the following on 7/18/2006 1:00 PM:
The newsgroup FAQ has not been posted here for some considerable while.

But links to it, and sub-articles of it, are posted at least daily. Many
times more than once a day.
The latest version I know of is 8.1 - 2005-11-05

That version is online, but not on jibbering.
<URL: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/>

It was put there, from your version, just so the latest would be available.
but I think the Web site serves 8.0 - 2004-03-15

It does. And if nothing else it could be updated to a static file so
that at least the latest version is on the website.
We cannot expect new readers, especially those entering via Web pages,
to know of the FAQ without a regular posting of something with a
suitable Subject, whether it be a FAQ or a FAQ pointer - and the Subject
must be such as they will understand ("Quick Answers" is OK; IMHO "META"
is not).

Either/Or, people do not read that far into the subject line.
As far as I know, the existing technical content is correct; but the FAQ
could IMHO be improved by re-wording here and there. I don't know how
many <FAQ**TRY> items remain outstanding.

That shouldn't be hard to determine. Even using Google Groups and
searching for the phrase and then sorting by date and going to the date
of the last update.
Is it time for someone else, someone who (unlike me) has access to a
system which can post regularly, to take over the FAQ?

If nothing else, I can post it manually with an FAQ Poster name until it
can be automated again. It won't be at the same time, but I can post it
Monday Wednesday and Friday. I don't care to "take over" it for editing
purposes but I can post it until......
ISTM that those from smaller countries in mainland Europe, having been
taught properly, seem to write good straightforward clear English.

Ahh, couldn't even discuss the group FAQ without letting your
anti-American sentiments display?

Your ignorance is overwhelming at times.
 
R

Randy Webb

Matt Kruse said the following on 7/18/2006 3:06 PM:
Your xenophobia is so blatant as to be amusing.

Right idea, wrong term. John doesn't suffer from zenophobia, but
stupidity isn't a condition so he can't suffer from that either
(although he does).

It is not all foreign things, it is strictly anti-American and anything
to do with it. Irony is that he uses many many American inventions to
spout his anti-American bull crap.
 
J

Jim Ley

Dr John Stockton said the f

It does. And if nothing else it could be updated to a static file so
that at least the latest version is on the website.

An email highlighting that fact would've been great! I've updated the
faq site to that one, automated posting - I can provide a box with a
news.individual account, and if you're "known" to me then I can
provide a log on, I unfortunately simply don't have any obvious time
to get it updated to automated posting.

Help of course welcome.

Jim.
 
B

Bart Van der Donck

Dr said:
[...]
We cannot expect new readers, especially those entering via Web pages,
to know of the FAQ without a regular posting of something with a
suitable Subject, whether it be a FAQ or a FAQ pointer - and the Subject
must be such as they will understand ("Quick Answers" is OK; IMHO "META"
is not).
As far as I know, the existing technical content is correct; but the FAQ
could IMHO be improved by re-wording here and there. I don't know how
many <FAQENTRY> items remain outstanding.

I think maintenance is one of the major challenges to guarantee a FAQ's
quality. One should ideally use some kind of system that constantly
reminds of the FAQ's content. Personally I like the idea of
comp.lang.perl.misc. An automated program posts one FAQ-entry a day to
the NG. If someone has a comment on that, it might be considered to add
it to, or rewrite, the FAQ entry in question. I think it's a great way
to keep things up-to-date (though I'm not saying that the Perl FAQ is
the ideal FAQ). Maybe http://faq.perl.org/ could be worth exploring to
see how things work there.
Is it time for someone else, someone who (unlike me) has access to a
system which can post regularly, to take over the FAQ?

I could make such a tool, that is, if you and the regulars of this
group wish to do so. It should consist of a logic and well-thought
structure. I think the current FAQ could be an excellent start, but I'm
convinced that it could cover much more topics. The great thing is that
there is much material available already, I think it would be great to
gather the information into one general list. I think it are the
unified contributions that make a FAQ strong.

One login/password could serve to maintain the FAQ. Probably it's a
good idea that everybody would keep his own topics; we'ld need a sort
of gentlemen's agreement for that. Or I could write a system with many
passwords so everyone has only access to his own FAQ entries.

Unfortunately, I don't have too much time on my hands to actively work
on and maintain the FAQ. Though the temptation to write an entry here
or there will probably pop up anyhow :) I could provide in the
technical background though and guarantee its correct working. I've
worked on many MySQL/CGI software projects over the past 7 years and I
cannot imagine that this relatively simple program could ever be
problematic. I have good contacts within pair Networks
(www.pair.com/www.quickserve.com), they are one of USA's largest
non-adult hosting companies. I'm quite sure they will give free app
hosting without need to mention their name/link. If you want to make
money, we could consider to add their name/link on each automated post,
but personally I wouldn't do that.

Another thing that comes to mind is that each FAQ entry should be
rather concise, and of course to-the-point and coherent. I think it
could certainly become a useful and maybe even the "de-facto" standard
for common javascript problems.

Vanity is of humans, and I think we can use this aspect to improve the
FAQ. The author(s) of a contribution can be mentionned below each
entry. Contributors might be sensitive for that, and as long as it
serves the FAQ, I don't see any drawbacks here.

I think a first major issue would be to make a solid structure that (a)
is more-or-less complete, (b) leaves room for future extensions and (c)
is intuitive to navigate.

In the long run there are a few things to consider. Not all current
contributors will remain interested to maintain their entries. I think
that problem can be dealt with; "new" regulars will appear in CLJ and
they can be invited to take over FAQ-entries after they've proven their
qualities. Obviously, one should try to make each entry as timeless,
qualitative and complete as possible. Another point is the continuity
of the technical background. As pair Networks has a long-proven
tradition of quality hosting with many dedicated machines, I think that
this shouldn't be a problem at all. About myself: I'm in business since
1999 and I can say I've solid business for many years to come.

I'ld be happy to know what you think about this :)
ISTM that those from smaller countries in mainland Europe, having
been taught properly, seem to write good straightforward clear English.

The issue is that non-native English speakers don't have much choice if
they want to express a software problem in a language that's not their
own. Especially in the beginning, you are forced to write as clear and
straightforward as possible, just because you don't understand the
exact finetunings and the connotations that words, sentences or
language constructions might have, while they are mostly immediately
obvious for native speakers. You can't translate Shakespeare to
Schwarzenegger-English, but you can describe a technical problem in
Terminator-language. I even think non-native English speakers have an
advantage here; they can't easily hide behind vague blah-blah or
unreadable terminology.
 
D

Dr John Stockton

JRS: In article <[email protected]>, dated Tue, 18 Jul 2006
14:06:07 remote, seen in Matt Kruse
Your xenophobia is so blatant as to be amusing.

Either you do not understand the difference between xenophobia and
xenophilia, or you are unaware of (a) what countries are, and are not,
basically in mainland Europe, (b) the relative sizes of European
countries. Or, of course, both.
 
M

Matt Kruse

Dr said:
Either you do not understand the difference between xenophobia and
xenophilia
Possibly.

or you are unaware of (a) what countries are, and are not,
basically in mainland Europe
Possibly.

(b) the relative sizes of European
countries.

Possibly.

What I do know for sure is that your assumptions and generalizations about
people based on their physical location and country of origin make you look
foolish.
 
I

Ivo

Matt Kruse said:
Dr John Stockton wrote
What I do know for sure is

death and taxes, all else is theory. Aren't we getting a bit off topic,
guys? Isn't that what this group suffers from most? I am from Holland, the
largest of the little countries, and the smallest of the big brothers on the
European block. The Javascript language transcends all that, as Bart Van der
Donck pointed out in another branch of this thread.
If this or any FAQ is to be of any value, it needs to change when
circumstances change, which they do continuously. What is the plan to get it
on the road again then, where lies the ultimate responsibility? Hadn't the
brave new anarchistic internet done with all that? Gentleman's agreements,
like others, rely not on vanity alone.
It is obvious that many people care about c.l.j. passionately, and plenty of
others also, but less, we all want the one and only FAQ to be perfect, but
what is to the point at one point in the web will never be so again, history
learns. Wouldn't a wikipedialike structure, where all may contribute on the
spot, with or without password, be conceivable?
hth
ivo
 
D

Dr John Stockton

JRS: In article <[email protected]>, dated Wed,
19 Jul 2006 20:47:13 remote, seen in Ivo
It is obvious that many people care about c.l.j. passionately, and plenty of
others also, but less, we all want the one and only FAQ to be perfect, but
what is to the point at one point in the web will never be so again, history
learns. Wouldn't a wikipedialike structure, where all may contribute on the
spot, with or without password, be conceivable?

It would be conceivable - indeed, I don't know what's on Wiki itself.

It could be a useful adjunct, but it could not rightly replace a
properly maintained newsgroup FAQ.

A proper newsgroup FAQ is maintained by a chosen individual; but, when
it is posted regularly in the group, the regulars can take joint
responsibility for reviewing it and ensuring that it is free of error.

One can see, from the alleged answers posted in this group by newcomers
whose estimate of their own ability greatly exceeds their experience,
knowledge, and sagacity (and also from the quality of topic-FAQ sites
that contain code collected from or provided by multiple sources), how
bad a result could come from unrestricted Wiki editing. ISTR that the
absent but unlamented one was proposing to alter true Wiki's news-
etiquette materials to agree with his own national practices.

So, if someone wants such, let it be created; and let it be cited and
reviewed for quality in the true newsgroup FAQ.

Note : we have already in this thread two fine examples of the
comprehensibility of English written by those in the smaller countries
of Europe in which English is properly taught.


ISTM that BVdD's proposal of posting parts-for-comment is an excellent
scheme; the individual parts X.Y are mostly not too large. Section 1
could be split into two or three; Section 2.3 could be split into, say,
General, Questions, Responses; Section 3.2 could be subdivided.

Some parts of 2.3 could be reworded more positively, on psychological
grounds - e.g.
CURRENT : 'Help!' or 'I hate Netscape!' are not nearly as useful to
contributors who do not read every post as 'parseInt("09")!=9'.
ALTERED : Subject lines such as "parseInt('09') != 9" or "Javascript
formatter?" are much more useful than ones such as "Help!" or "I hate
Netscape!".
 
R

RobG

Ivo wrote:
[...]
It is obvious that many people care about c.l.j. passionately, and plenty of
others also, but less, we all want the one and only FAQ to be perfect, but
what is to the point at one point in the web will never be so again, history
learns. Wouldn't a wikipedialike structure, where all may contribute on the
spot, with or without password, be conceivable?

If you wish to contribute to a wiki, then feel free to help with:

DOM
<URL:http://developer.mozilla.org/en/docs/Gecko_DOM_Reference>

JavaScript
<URL:http://developer.mozilla.org/en/docs/JavaScript>

You can also help out on wikipedia, however that is an encyclopedia and
will therefore never be a comprehensive JavaScript reference.
 
D

Dr John Stockton

JRS: In article <[email protected]>,
dated Wed, 19 Jul 2006 02:48:26 remote, seen in
news:comp.lang.javascript said:
I think a first major issue would be to make a solid structure that (a)
is more-or-less complete, (b) leaves room for future extensions and (c)
is intuitive to navigate.

It is always possible that a newsgroup FAQ maintainer will lose interest
for one or more of several reasons.

Therefore, the FAQ-writing system should not require anything other than
ordinarily-available software. That's automatic for a plain-text FAQ
(except that not everybody here can CRON a news-post); but not so if the
need is to maintain plain-text and HTML versions from a single source.

Now <URL:http://www.merlyn.demon.co.uk/js-quick.htm> is available for
all to take and use (but not re-publish) a copy of; and it can take
paragraphs of arbitrarily-varying line-length and convert them to left-
justified at a given margin size.

ISTM that something vaguely similar, but with more javascript code
behind it, could possibly take simple marked-up text and produce both an
HTML version and one suited to News, perhaps in new windows.

Example :

H2 some heading
text /text/ ... <URL:... ...>

could convert to

<H2>some heading</H2>
<p>text <i>text</i> ... <a href="...">...</a>

and to

some heading

text text ... <URL:... ...>

This would of course be much simpler than a general text->HTML or HTML-
text converter as it does not need to deal with any construction that
the FAQ does not need to use. Being javascript, it would if prudently
written be usable and maintainable by any FAQ maintainer.
 
B

Bart Van der Donck

Dr said:
[...]
It is always possible that a newsgroup FAQ maintainer will lose interest
for one or more of several reasons.

Therefore, the FAQ-writing system should not require anything other than
ordinarily-available software. That's automatic for a plain-text FAQ
(except that not everybody here can CRON a news-post); but not so if the
need is to maintain plain-text and HTML versions from a single source.

Thanks for the comment, John. You're absolutely right that a FAQ
maintaining system shouldn't require anything else than commonly
available software. I had thought to make it accessible for all common
browsers.

When it comes to updating HTML documents from one single source, I
thought of the following possibilities:

(1) If the owner of an interested website is willing to give
username/password (S/FTP), then the software at my end could
automatically replace the file on a daily base. This does not require
any extra tools, as I assume all websites are accessible by FTP one way
or another. Of course I can understand that not all website owners are
willing to share their FTP login data.

(2) Programmers familiar with PHP, ASP, Python, Perl, Ruby, Java, C++,
etc. might fetch the URL of my generated output file, and then replace
the file on their own website. You're right; this requires some effort
from the website owner and he needs to have access to those
technologies.

(3) Send out the content by mail. It's possible, but, same as (2), the
mail should be processed then using own tools.

(4) Web service. It's possible to set up a web service using socket
communication, or over HTTP. Maybe some would like to work with
javascript's XML HTTP Request object / AJAX, this would also be a
possibility. Maybe HTTP is easier here, as I'm not sure whether it's
possible to communicate to other ports than those from the web server
when using AJAX.

If anyone would have additional ideas for more possibilities, then I
can always consider those.

Points (1) to (4) are thougth as different possibilities that can all
exist together. Once a website has its daily FAQ-update (whether by
(1),(2),(3) or (4)), it just keeps running and there is no need to do
anything else; so one can focus on the content only.

It's not hard to generate an HTML file from SQL data. And maybe we
could eventually skip the HTML idea and just spread it as XML.
Now <URL:http://www.merlyn.demon.co.uk/js-quick.htm> is available for
all to take and use (but not re-publish) a copy of; and it can take
paragraphs of arbitrarily-varying line-length and convert them to left-
justified at a given margin size.

ISTM that something vaguely similar, but with more javascript code
behind it, could possibly take simple marked-up text and produce both an
HTML version and one suited to News, perhaps in new windows.

Example :

H2 some heading
text /text/ ... <URL:... ...>

could convert to

<H2>some heading</H2>
<p>text <i>text</i> ... <a href="...">...</a>

and to

some heading

text text ... <URL:... ...>

This would of course be much simpler than a general text->HTML or HTML-
text converter as it does not need to deal with any construction that
the FAQ does not need to use. Being javascript, it would if prudently
written be usable and maintainable by any FAQ maintainer.

I've played around with this tool; yes, I think this would be an
excellent tool to generate XML/HTML before it's inserted into the
database. The stored data should contain all HTML/XML tags anyhow, but
it's a good idea to make the life of the FAQ-maintainer as easy as
possible.

Let's say that the basic CGI-2-SQL program works with a simple
<textarea></textarea> to maintain a chosen FAQ-entry. When the system
is running, this textarea can then be extended to contain any
"additional" client code, to reduce the manual 'hard'/'HTML' work as
much as possible.

But I would prefer that the CGI/MySQL is developed first; because your
tool can always be built upon the underlying mechanism (the other way
around is more difficult). In other words, the system can work with a
simple textarea, but this textarea can be extended to "virtually
whatever", as long as its posted content at the end is the same as it
would be as a simple textarea. It's like the Hotmail-system; all kinds
of features to insert the content as effective/user-friendly as
possible; but always post the resulting HTML/XML at the end. Are you
open or this idea ? I'm just trying to think of a suitable workflow
here :)

The storage of all data should be in structured format; that is,
preferrably a database. This is much easier for the developer. When
cron fires off its daily post, it's logical that it would take its
content from a database. At least in my experience this would be the
best approach for such scenarios. Of course it is always possible to
program an own relational system for the FAQ, but that would actually
be reinventing the wheel.

The Usenet article could then just consist of the FAQ-entry in question
without the markup tags (so, in plain text, with after <p></p> two EOLs
&& after <br> one EOL). These EOL regexes and strip-HTML regexes are a
oneliner in Perl, and can easily done by the cronjob just before it
sends out the Usenet-post. And then some practical stuff like start
text / entry title between hyphen ranges at the top / etc... it should
be no big deal.

I hope to have clarified more than confused.
 
J

Jim Ley

(1) If the owner of an interested website is willing to give
username/password (S/FTP), then the software at my end could
automatically replace the file on a daily base. This does not require
any extra tools, as I assume all websites are accessible by FTP one way
or another. Of course I can understand that not all website owners are
willing to share their FTP login data.

I certainly wouldn't make a website available to FTP, and I see no
reason to provide FTP simply to have SFTP when there are much better
methods.

The bigger problem with automatic updating of content generated from
an unknown webapp that allows html input, is avoiding insertion
attacks, or even simply avoiding spam - web versions of FAQ's tend to
be high ranked so well worth getting links on.

As I've said many times, any known person who wants a log in on my box
to manage the FAQ is welcome to one.
I've played around with this tool; yes, I think this would be an
excellent tool to generate XML/HTML before it's inserted into the
database. The stored data should contain all HTML/XML tags anyhow, but
it's a good idea to make the life of the FAQ-maintainer as easy as
possible.

wiki like markup are well understood and solved problem, don't invent
new syntaxes.

Jim.
 
B

Bart Van der Donck

Jim said:
I certainly wouldn't make a website available to FTP, and I see no
reason to provide FTP simply to have SFTP when there are much better
methods.

The possibilities I mentionned are those that I've experience with, and
of which I know they work well. I'm open to any other methods that are
programmable in CGI/Perl.
The bigger problem with automatic updating of content generated from
an unknown webapp that allows html input, is avoiding insertion
attacks, or even simply avoiding spam - web versions of FAQ's tend to
be high ranked so well worth getting links on.

Yes, that risk would always exist. Perhaps it would be best to have 1
password and 1 person to manage the FAQ. If the password is kept safe,
I don't think the application would be insecure.
As I've said many times, any known person who wants a log in on my box
to manage the FAQ is welcome to one.

Sorry, it was not my personal intention to actually manage the FAQ. I
don't have enough time to do it well, and there are posters in this
group who have much more javascript knowledge than I.

I might help in writing the software that I proposed, as my 'historic'
knowledge is roughly UNIX/CGI/databases. IMO the software could make
things more maintainable, efficient, and easier adaptable; but it's up
to you guys to decide, of course.
wiki like markup are well understood and solved problem, don't invent
new syntaxes.

Actually the markup syntax in a textarea wouldn't matter. This might be
Dr John's tool (which would be a excellent choice, IMO), or a wiki-like
tool, or none, or ... The only requirement from my point of view is
that the content is POST-ed as HTML/XML that is ready to insert in
database with its full markup.
 
B

Bart Van der Donck

Jim said:
(1) If the owner of an interested website is willing to give
username/password (S/FTP), then the software at my end could
automatically replace the file on a daily base. This does not require
any extra tools, as I assume all websites are accessible by FTP one way
or another. Of course I can understand that not all website owners are
willing to share their FTP login data.

I certainly wouldn't make a website available to FTP, and I see no
reason to provide FTP simply to have SFTP when there are much better
methods.

The bigger problem with automatic updating of content generated from
an unknown webapp that allows html input, is avoiding insertion
attacks, or even simply avoiding spam - web versions of FAQ's tend to
be high ranked so well worth getting links on.
[...]

Another (better?) project description could maybe consist of the
following:

- Crontab file starts up Perl program once a day
- Perl program grabs http://www.jibbering.com/faq/index.xml
- Checks on successful GET-request, valid XML, well-formed XML,
security, etc.
- Determine which FAQ-entry is to send to Usenet
- Parse XML and extract the part we need
- Format message towards Usenet and fire it off
- Keep track of which FAQ is to be sent next time (number)
- Exit

Of course, this scenario is simpler as my initial proposal. It doesn't
touch anything about the way the current FAQ (or its
maintainance/structure/contents) works. It's just an add-on that is
responsible for the sending of one-FAQ-entry-a-day, and that's it.

I investigated the structure of http://www.jibbering.com/faq/index.xml,
this should be suitable; some questions:

- What does the "hash"-argument of the <URL> tag mean ?

- As Richard said, the code examples should be adapted in the data so
that it doesn't exceed 68 characters per line.

- It should be logical that each FAQ-entry would have its number in the
XML-data as well. This would be easier for Perl to remember which
FAQ-entry is to send the next day. Now Perl needs to invent its own
counting mechanism to determine which FAQ-entry is to send out. (which
shouldn't be a problem technically though, so generally this point is
only a side-remark). But when new entries are added in the future, this
might at some point result in a jump/reverse in the counting mechanism.
I don't know about the possibilities of something like
<FAQNR>4.22</FAQNR> or <CONTENT FAQNR="4.22">.

- As a professional pedantrist, it would be better practice to start
with <?xml version="1.0" encoding="UTF-8"?> , use some DTD/schema
info and do
<CHAPTER TITLE="Quick Answers" CHAPNR="4">
in stead of
<CONTENT TITLE="Quick Answers">
and perhaps
<FAQENTRY TITLE="What is ECMAScript?" ENTRYNR="7">
in stead of
<CONTENT TITLE="What is ECMAScript?">
to get the touch of real XML-ish structurisation. If you want to, I
could adapt the XML file that way. But the current XML structure is
suitable as well (these are optimisation issues only).
 
R

Richard Cornford

Bart Van der Donck wrote:
- Determine which FAQ-entry is to send to Usenet
- Parse XML and extract the part we need
- Format message towards Usenet and fire it off
- Keep track of which FAQ is to be sent next time (number)
- Exit

Where did this notion of posting one entry a day come from? At that
rate it would take a month and a half to cycle trough the existing
entries (longer is many get added) and it does not appear that section
2 would be getting posted at all, when section 2 is probably of more
practical significance to people trying to get answers from the group
than anything in section 4.

The previous approach of posting half the FAQ at a time once a week,
while not meting with universal approval, may be the better basis for
an improved system.

I investigated the structure of http://www.jibbering.com/faq/index.xml,
this should be suitable; some questions:

- What does the "hash"-argument of the <URL> tag mean ?

It was automatic monitoring for changes in linked pages. It went; load
the page with an XML HTTP request, if the HTTP status is 200 hash the
source text and compare the source text with the existing hash, if they
differ the page has changed. It has not been being used for some time,
but the 'hash' attribute has not been removed.
- As Richard said, the code examples should be adapted in the data so
that it doesn't exceed 68 characters per line.

I did not say that. The existing entries are formatted so that their
line length (in the text output format) is less than 72 characters.
Remember that a set of characters may not appear in non-CDATA XML
contents and so need to be transformed into apparently longer entities,
that similar considerations apply to HTML (and so are introduced by the
need to present the contents as HTML), and that characters commonly
used in javascript fall into that category.
- It should be logical that each FAQ-entry would have its number
in the XML-data as well.

A sensible move if anything were to be changed would be to stop
thinking of these as numbers at all and only use then as instances of
arbitrary identifiers to be used as fragment identifiers). They would
need to go in the actual XML, and become a required attribute for all
the conceptual units to which they currently apply, though the values
for future additions could then be non-numeric, and at least
semi-meaningful in some cases.
This would be easier for Perl to remember which
FAQ-entry is to send the next day. Now Perl needs to invent its own
counting mechanism to determine which FAQ-entry is to send out. (which
shouldn't be a problem technically though, so generally this point is
only a side-remark). But when new entries are added in the future, this
might at some point result in a jump/reverse in the counting mechanism.
I don't know about the possibilities of something like
<FAQNR>4.22</FAQNR> or <CONTENT FAQNR="4.22">.

- As a professional pedantrist, it would be better practice to start
with <?xml version="1.0" encoding="UTF-8"?> , use some DTD/schema
info and do
<CHAPTER TITLE="Quick Answers" CHAPNR="4">
in stead of
<CONTENT TITLE="Quick Answers">

No. Quick answers is section 4 only because there are 3 preceding
sections. Starting to hard code numbers intended to be presentation
sequences is just re-introducing the problem caused by automatically
generating numeric fragment identifiers from the existing sequence, but
in a different guise. The XML element that represents 'quick answers'
can contain and identify its contents without any need for it to be
'chapter 4'.
and perhaps
<FAQENTRY TITLE="What is ECMAScript?" ENTRYNR="7">
in stead of
<CONTENT TITLE="What is ECMAScript?">
to get the touch of real XML-ish structurisation.

Again, numbering is too presentational and ridged. I can understand
attributes that describe categorisation/classifications for individual
entries (for presentation grouped into related subjects), but sequenced
numbers are something that needs to be moved away from.
If you want to, I could adapt the XML file that way.
<snip>
Requests for presentational changes include a reoccurring desire to
have parts of section 2 presented as an ordered list (so individual
paragraphs can be references) and to be able to present links, which
must be text URLs in plain text format, as meaningful text that is a
hyperlink in HTML. The former is probably easily achieved in the
transformation from XML to content, but the latter will require an XML
representation containing enough information to generate sensible
content in either (any?) context of use.

Richard.
 
B

Bart Van der Donck

Richard said:
Where did this notion of posting one entry a day come from? At that
rate it would take a month and a half to cycle trough the existing
entries (longer is many get added) and it does not appear that section
2 would be getting posted at all, when section 2 is probably of more
practical significance to people trying to get answers from the group
than anything in section 4.

I think it was I who came up with it; it was inspired by
comp.lang.perl.misc. Posting one entry a time might be more efficient
for continuous evaluation/improval, rather than posting a large
document. Plus, I think a concise && well-defined message is more
inviting to respond to. I think it would also become easier to Google
for specific js questions.
From the rest of your post I can conclude there are no practical
problems from CGI point of view. So, okay with that. But I get a
feeling that my code proposal is about burnt to ashes by now :)
[...]
- As a professional pedantrist, it would be better practice to start
with <?xml version="1.0" encoding="UTF-8"?> , use some DTD/schema
info and do
<CHAPTER TITLE="Quick Answers" CHAPNR="4">
in stead of
<CONTENT TITLE="Quick Answers">

No. Quick answers is section 4 only because there are 3 preceding
sections. Starting to hard code numbers intended to be presentation
sequences is just re-introducing the problem caused by automatically
generating numeric fragment identifiers from the existing sequence, but
in a different guise. The XML element that represents 'quick answers'
can contain and identify its contents without any need for it to be
'chapter 4'.

No problem; leaving out numberings could be worked around - the (small)
risk here is that Perl could be mistaken when the FAQ is updated.

Oh yes, when re-reading my joke above, I only referred to myself as the
"professional pedantrist"; I'm not sure it was read that way. You see
Dr John, that happens to non-native English speakers :)
 
D

Dr John Stockton

JRS: In article <[email protected]>
, dated Mon, 24 Jul 2006 03:08:52 remote, seen in
Richard Cornford
Bart Van der Donck wrote:


Where did this notion of posting one entry a day come from? At that
rate it would take a month and a half to cycle trough the existing
entries (longer is many get added) and it does not appear that section
2 would be getting posted at all, when section 2 is probably of more
practical significance to people trying to get answers from the group
than anything in section 4.


It should be (whatever the intention was), that one entry a day would be
posted, for purposes of specific review by the regulars against
staleness; but that the existing weekly posting of the whole FAQ, to
enlighten the ignorant, would be maintained though possibly modified
into three distinct parts.


The whole material, apart for the index, should be covered by the review
process; and to improve this Sections 2.3 and 3.2 should be subdivided.

FAQ 5.1 paragraph 2 sentence 2 could be made unimportant if the
<FAQ!!TRY>-seeking process were to ignore lines starting ">". However,
such replies ought to be considered.

<FAQENTRY> 5.1 para 1 :-
?? If a poster feels that a topic should be covered by the FAQ, placing
<FAQENTRY> in the article will let the FAQ robot collect the article for
easy review and inclusion. A draft response, if possible, will be
welcome. ??
 
B

Bart Van der Donck

Dr said:
[...]
It should be (whatever the intention was), that one entry a day would be
posted, for purposes of specific review by the regulars against
staleness; but that the existing weekly posting of the whole FAQ, to
enlighten the ignorant, would be maintained though possibly modified
into three distinct parts.

The whole material, apart for the index, should be covered by the review
process; and to improve this Sections 2.3 and 3.2 should be subdivided.
[...]

Okay, I'll leave the actual divisions/content up to the FAQ maintainer.
This stands apart from the technology that is used for the daily Usenet
message anyhow.

Thanks for the explanations Jonh/Richard/Jim; I have enough information
now. I'll develop the code:

- Crontab file starts up Perl program once a day
- Perl program grabs http://www.jibbering.com/faq/index.xml
- Checks on successful GET-request, valid XML, well-formed XML,
security, etc.
- Determine which FAQ-entry is to send to Usenet
- Parse XML and extract the part we need
- Format message towards Usenet and fire it off
- Keep track of which FAQ is to be sent next time
- Exit

Because the XML doesn't work with FAQ entry numbers, I'll deal with
this as follows:
- see how many FAQ entries are in the XML file
- read out stored value that says which entry was sent the previous
time (e.g. it was the fourth entry then)
- parse XML and extract (in this case) the fifth entry. If fifth entry
doesn't exist, take back the first.

See you after some time when I'm ready.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top