Date: Tue, 26 SEP 1995 17:35:49.56 -0600 (CST) From: Alan Jonckheere (708)840-3158 To: @Tools.dis Subject: RE: Minutes of the last Tools mtg Hello everyone, I was just going over the minutes of the last Tools mtg and have a couple of comments and questions. Since I wasn't there, I don't know the details of the discussions, especially about the single source "goal". However, from what I can gather from the minutes, there is some misunderstandings of my recommendations on this subject. But before I get to that: I have no problem at all with changing "allowed" to "supported" everywhere. In fact, I like that wording much better. ------------------- The whole thrust of my recommendation on single sources is that the *official source* of all documents be available directly through whatever Web browser you are using. It should *not* be necessary to exit your browser and go through a lot of gymnastics to obtain the original source in order to modify it (but see below re Serban's suggestion). Furthermore, a user shouldn't have to have relatively rare software in order to successfully update a document. I did *not* "recommend that all documents be converted to HTML. This is obviously impossible. Source code is one class of "document" that can *not* be and *should* not be written in HTML. The documents submitted to a journal are another. Both of these were mentioned in my recommendations. HTML is a *goal* only because it allows use of the full power of the Web. But I explicitely stated that other formats would be "allowed" (now read "supported). The confusion seems to have occured when I discussed allowing "non-supported" document preparation systems to be used by allowing "conversion" to a supported form, such as HTML. I think I went to too much length there and just got you all confused. My point was that it *must* be the "supported" form that becomes the "source" for future updates, especially if anyone other than the original author, or someone with access to his/her original files and software, is to make updates. The example of a Journal article, which would be in TEX/LATEX/REVTEX, and an HTML version is an example of a case where *two* sources would be allowed. One of them, the original journal article would have updates forbidden. So, in fact, there is only one source that could ever need maintainence. Am I making myself clear? The existence of links is irrelevant for this argument. The key point is that anyone who has a legitimate need to update a document should be able to do so without a lot of gymnastics, and with some confidence that their update won't be superceded by someone else updating at the same time. Note also, that none of this makes any difference if a single user is and always will be the only one maintaining a document. There are many classes of such documents. In that case, they'd have to supply *some* form that is viewable/printable but not necessarily fetchable via a browser. If Serban's suggestion of having a single front end to insert documents into the system can be satisfied (I'd thought of that, but have no idea how to do it, or how much work it'd be, or how to enforce it's use) then *any* format that can be handled by that frontend would satisfy my requirements of "single" sourcing. And in fact if the same front end where required to fetch the source, then I'd even be willing to relax the requirement that the Web Browser must be able to fetch it. In fact, this single gateway would make things a *lot* easier to control. I don't know how we'd enforce it though. ---------------- What "additional specifics regarding search features/restrictions" are you adding? I don't have any particular bias there since I don't really know what's possible or desireable, just that finding the document you want isn't easy without a rather advance search capability. --------------------- Tech stuff. I was trying to get a dialog going. I wanted people to realise that just "use the Web" doesn't answer all questions. How in the world would you "update all links automatically"????? -------------------- USENET: Several Usenet readers are available on VMS as well. The two readers that FNAL supports in the LIB:[LIB] area are ANEWS, a GUI interface and NEWSRDR, a command line reader. At least these are the two I've found. The point of mentioning this is that we do *not* have to wait for the full shift to Unix to use them. USENET is also available through the WWW (http://www.w3.org/hypertext/DataSources/News/Groups/Overview.html) The VMS readers keep the subscription list in a text file in the users home directory, just like UNIX. Why would it be different? One more point about USENET. It's possible to filter out particular catagories of groups. I don't believe it's possible for us (at FNAL anyway) to access the pornographic groups for example. Those are filtered out by some bridge or router before they get onto the site network. I remember, vaguely hearing about them being intercepted. At one time, they *were* accessable and some people got into a lot of trouble because of it (unauthorized use of govt property etc.). ----------------------- Web group: is that in our perview? I'd like to be in it. ----------------- Please send me your updated/revised draft before you send it out to the rest of the commitee. I think that there was enough confusion with the original, and from the minutes it's likely to extend to the next version that I'd like to get another go round before it goes to the whole committee for ratification. Alan