|
ISO/IEC JTC 1 N4576R |
This paper provides guidance on how to create and maintain web pages for ISO/IEC JTC 1 standardization committees. It also contains a proposal for a stucture of the pages and prototype pages. The scope only applies to ISO/IEC JTC 1 and its subcommittees, in the following named "committees", but WGs within the JTC 1 and other ISO or IEC committees may also benefit from the tips in the paper. This paper is an implementation guide for the JTC 1 document N 4572 "ISO/IEC JTC 1 Web Server Policy". The intended audience is people responsible for the implementation of the JTC 1 web policies, such as committee secretariats, and their helpers.
The pages should be made so it is straightforward to generate it out of existing TC or SC material, combined with the produced prototype web pages. The prototype pages have been made in a HTML-utilitities independent, portable and strictly conforming (to HTML 2.0) way, so they should be easy to use for integration. Basically what is needed is the scope of the committee in question, the chairman's or secretariat report to the parent body, or the business plan, the membership and liaisons lists, and then possibly descriptions of standards for example as text from the originating NP. Keld Simonsen, [email protected] has offered to help in merging the committee materials with the HTML sources, as well as offered hosting of the pages.
The committee web pages should be structured so that they are readable, also as a freestanding paper submission, as these pages here are also an example of. Normal style guidelines for good web documents, many available on the net, should be adhered to.
The structure of the prototype pages are:
The rest of the information scheduled as per this proposed web structure has been checked with the current ISO guidelines for document distribution, with special permissions for JTC 1, and should be OK for general distribution, as the following document types are classified for "open" distribution: Document register, secretariat report, programme of work, meeting notice, meeting agenda, meeting report, meeting resolutions, together with procedural information. As NPs are project related, these are also permitted for open distribution, under the one year trial period granted by the ISO TMB. Committees may chose to make another division of the distinction between public and restricted pages.
For restricted access, the password protection of most web servers can be used. For FTP protection, one can use a non-anonymous ftp account, or a hidden directory.
For mirrorring web pages, it is advisable to only use ftp mirroring, as there are a number of problems with web mirroring using the HTTP protocol.
A number of resources are drawn upon, including the ISO and IEC web servers.
A number of guidelines for each of the documents is given below.
The structure of the web pages most likely will differ somewhat from committee to committee and will also neccesarily develop over time, but some structure should be kept common, also for use in general ISO-wide text retrieval and web systems.
A specification in a web page of which documents there are and the naming conventions and reference conventions should be explained to possible referrees, and should not be changed lightly.
The complete web pages should be registered so they can be used, amongst other places at the ISO web pages.
It is important that the web pages are well kept. A way to do this is to have a direct relation to information already being generated by the committee, such as chairman's, or secretariat reports, project status, membership lists, ftp archives etc. As the web pages are advised to be readable clear text, the web document could be the same as the normal official document (or said in another way: the official document could be the web page).
Some of the information needed may be automatically updated, like ftp archive contents and email subject list, and some may be done already by other sources, such as updated standards lists from ISO.
You should check your document for correct HTML before releasing it. A syntax checking service is available at http://www.webtechs.com/html-val-svc/mirror_sites.html
You should also check the set of pages for links that are erroneous.
Tools and template web pages will be produced or collected, and made available for JTC 1 use. Please contact the author, Keld Simonsen for suggestions.
In the following the contents of each of the pages will be described, along with some guidance on the contents. Not all pages have been described in this document, but information will be furnished in a later version.
The design of the "index" page is that the page has general information for a casual interested person, while still being adequate also for work within the committee.
A user can find:
The HTML formatting requirements are very straightforward HTML. No complex capabilities are required for creating or viewing such pages. Also it is advised that a minimum of graphics is being employed, as these may take a long time to download and thus may irritate the user, possibly to the extent of not getting the information.
There should be backpointers in the beginning of the text to the parent bodies on the homepage. On pages other than the home page, the committee name points back to the committee home page.
For the ISO and IEC bodies their logos are used, as also done on published specifications and committee documents etc. In addition, an ISO/IEC background could be given, so that a reader will know whenever official JTC 1 documentation will be read (and note when a pointer to non JTC 1 documentation is followed).
The items Contacts, etc. in the body are links to other pages with particular recommended formats (see subsequent pages of this document). Subitems are pointers to the headings within those pages.
If there are no items for an information topic, the item (e.g., "News") may be omitted from this list and no corresponding page need be generated. If a category name is not required (e.g., "Projects"), it may be omitted as well.
The page is designed to give a fair description about the committee at a first reading. The intended audience is users of the standards produced by the committee, that could be programmers, software architects, consultants, and other standardizers. That is a fairly technical audience - but these are the people that pay for the standards and pay attention to the work.
An emphasis is made on the products of the committee - what can be used by a broader audience.
For people that use the page as a way of looking up information there are hotlinks at the very beginning of the page. The same links are explained and hotlinked later, for more novice users.
The text is rather short, to convey the information to the user without having to look thru a lot of pages. The client user screen is normaly quite limited in size and it is avoided to use a lot of graphics. The two logos are only about 2 k each. It is also avoided to use a lot of paragraph headings and paragraph numbers, to make the page less formal and to conserve space.
For totally newcomers there is an initial statement of this being a international standardization working committee.
The user is referenced to the member body for further info. There are no long references to ISO, IEC etc., but hotlinks are provided. The casual user should not be tired by ISO administration, but get access to the products (the standards cannot be provided but maybe we can provide some interesting material to him/her).
Project numbers should be avoided, as they are quite formal and do not tell people outside the standardization committee anything. They may be included on followup pages. Anyway ISO is now using the final standards numbers as project numbers, eg JTC1.22.14652 .
For the committee member use there should be hotlinks in the very beginning of the homepage, making use snappy and easy. and also meeting information for upcoming meetings.
There is provision for restricted access to committee and ISO documents.
There is a news button in the hotlist which is not referred to in the rest. The news section should be first - but then writing "read all about the interesting news" as the first sentence would be overkill, and the news button is first anyway. And there may not be that much news anyway.
A "stop press" entry as the first part of the index page could be included, given that the news warrants it.
The newest news should be listed first.
All news should be retained, as a history stack.
ISO 8601 dates should be used, in the form of the format 1996-01-19, to faciliate easy searching on dates, in millenium-safe form, and intervals should use the notation 1996-01-19/24, using a "/" to indicate the interval.
The page should have a list of the projects assigned to the committee, and also their status.
If there are no publications, the Publications section should contain merely "None."
The categories ("Committee Drafts", "Standards", "Technical Reports", etc.) are pointers to descriptions of the nature of these categories.
Pointers from the document should include all and only the public documents (active Standards, Committee Drafts available for review, Technical Reports, etc.) which have been produced by this committee.
It might be convenient to have a newest document list, or latest mailing list separate from the full register.
The newest documents should be list first to attact attention, so the list should be in reverse order.
Long tables should be avoided as the display of the table will only begin when all of the table is transferred. A list may better serve quick access to the information.
At least the document number, date, and title should be available in the main document register, and due date when applicable. Other document information could be available in a separate cover page.
There could be links to the actual documents here, with restricted access to the restricted documents. The document number could point to a directory with different format versions of the document and cover pages, and the title could point to the most accessible document.
Past meeting information should point to a working committee document, if any, containing the resolutions and minutes of the meeting. (Information about the meeting logistics, attendance, documents considered, etc. may be obtained from the minutes, which may itself contain hypertext pointers to home pages of representative bodies and committee documents.)
Future meeting information should point to a committee document containing details of the meeting plans and agenda, if available. Tentative meetings should be indicated as such.
provisions should be made for signing up for the meeting easily - remembering that committee meeting is only open to member body representatives, committee officers and liaisons of the committee.
information on meeting place, hotels etc. should be available
Contact information for both individuals and organizations might be "mailto:..." or conventional home page URLs.
Liaison information should only be provided for formal (committee-recognized) relationships.
Liaison can be listed with separate reference to liaisons from other committee to the committee, and to other committee from the committee. The name of the liaison can be listed, when explicit permission has been obtained from the person.
"name"-entries with the same name should be available for the following roles: chairman, secretariat, secretary, project editors, webmaster, postmaster, ftpmaster; project editors with the prefix "editor-" before the ISO number, for example "editor-99999-2".