xml-dev - Re: OASIS and XML-DEV

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

Firstly to thank the several people who have posted constructive solutions
to the list. Please continue

This is a difficult message for me to write and I ask for consideration and
constructive responses.

Firstly, I believe in the aims of OASIS and believe we need an organisation
to fulfill them. Such an organisation is appropriate to host XML-DEV. I
wish to see OASIS continue to be involved with XML-DEV. We have to have a
flourishing organisation with these aims. I would like, therefore, to see
an outcome where XML-DEVers, OASIS and others see a constructive way forward.

I do not wish to judge OASIS's business processes publicly. I am not a
member (cannot afford it), and have had no formal business communication
with them. I do not meet OASIS members in real-life except very
occasionally. Those OASIS staff whom I know personally, I greatly respect.  

I think we would all agree that OASIS has ambitious aims, that XML is
expanding very rapidly, and that they have a great deal on their plate.
(Just look at the site map).

However I have had no real communication with OASIS since the list moved,
and both Henry and I have found that private e-mail has neither solved the
problems nor given us an insight into how the organisation works. Therefore
everything I say from here on is speculation, and I shall be very careful.
I would obviously be grateful for any corrections.

Clearly OASIS have committed to support the list and this involves real
resources and we should publicly appreciate this. The following suggestions
assume that they wish to continue to commit resource (in some form) and
that we should try to design solutions which are as cost effective as
possible. It seems that there are attractive technical ways of outsourcing
some of the list activity which would reduce costs, increase the role of
volunteers and improve service. I hope OASIS is sympathetic to these ideas.
Ideally I would like us to reach a communally acceptable way forward.
Our thinking will have to be done in public, on this list. *** Please
therefore make sure that everything you post is constructive and aimed at a
win-win for everyone ***. It is not an easy process for some people,
because much conventional business is done face2face or over the phone. But
I am optimistic, so let's try...

Please correct any technical aspects :-)

The list activity breaks down into the following. Let us try to refer to
this with consistent terminology (capitalised here) if possible...

MAILLIST. This is the single essential component. At Imp College it
consisted of:
	1 LISTSOFTWARE Majordomo and majorcool software.
	2 A LISTSERVER machine and OS and 
	3 SYSTEMSTAFF to maintain 1 and 2 *generically*
	4. A LISTMANAGER (Henry)

	3 and 4 need not be the same person.
	1/2 could be provided by different technologies (e.g. newsgroups, etc.) UK
academia has a service (mailbase) for this purpose and we could have used
it for free. We judged the facilities provided were not as appropriate as
Imp College.

	Details of the ImpColl setup:
		Henry had no access to 1/2 other than occasional personal requests to the
staff (he could not hack any serverside stuff)
		Subscription and Unsubscription was automatic BUT:

			a high proportion of e-mails decay. These throw errors. Assuming there
are 10 rogue e-mails and 40 messages/day, Henry got 400 error messages/day.
These included failed unsubscriptions. When failed unsubscribers re-failed,
they would sometimes post their disquiet to the list! Manual attention was
the only solution. This was sometimes trivial, sometimes extremely
difficult and Henry became an expert at deciphering mail headers. This is
what took the time (4/5 hours per week). *** Anyone offering to run a list
should be aware of this - if anyone has a solution, fantastic.***
		There was no technical moderation (any member could post any content). It
is a tribute to the list that the only moderation is my and other members'
comments. If anything serious had arisen we would have had to manual remove
a subscriber. Note that it is NOT allowed to remove messages from an archive.

	*** Note that most of the concerns of list members fall into categories
1/2/3. Thus we need access to facilities on a machine which is:
		- robust
		- has high bandwidth
		- 24/7 support
		- competent *generic* maillist skills
		- hopefully - a channel of communication between 3 and 4!
	Therefore a generic ListServer, properly serviced will solve all the
time-critical problems. The ListManager is less time critical in that it
only affects subscribers, unsubscribers and errors. Some off-time may be
acceptable here (even henry had to sleep).

Note also that there was little need for Henry and me to interact on
moderation - we have never unsubscribed anyone against their will.
Therefore on the assumption that I remain as a moderatorial influence, I do
not need to have formal liaison with the ListManager.

	***Note that the MailList has to be associated with a domain name (at
present xml.org) and there is also a single subscription list of mail
addresses. Any transfer of MailList functionality has to address these
points. I would very much hope we can retain the xml.org domain name, even
if the ListServer is physically and organisationally distinct

HOMEPAGE
	This is not essential, but highly desirable. (We never had it at Imp
Coll). It need not have the same physical location or domain name as the
ListServer
MAILARCHIVE
	The primary archive is a standard mailbox (is this SMTP?). Henry and I
have the 3 year archive from IC in the form that it arrived and as far as
we know has every message. *** It is absolutely essential that this is
retained for posterity ***. I also think it should be GPLed, with
restrictions about how it is edited.
	In principle any person or org *** subscribed from the beginning *** has a
copy of this in their mailbox if they have not deleted any messages.
However with 20000 messages it is a fair amount of disk space.

HYPERMAIL
	This requires software which reads the mail as it comes in (or the
MailArchive) and creates a threaded display in HTML (or some similar
technology - XML :-). At IC they provided hypermail (I think).
	In principle this need not be on the same site as MailList, and in
principle there can be multiple copies or parallel efforts.


COMMUNAL RESOURCES
	We have not had communal resources so far, but I think this is what David
Brownell is suggesting. Again they do not need to be coupled to the
MailList, HomePage or MailArchive site(s).

We have had several suggestions (a few privately). This is not a complete
summary.

newsgroups, eGroups. Newsgroups (e.g. comp.text.xml) have to set up by a
formal vote and I don't think are appropriate. I would like detailed
technical comment on the other options, including domain name, subscription
list, mailbox, etc. 

volunteers.
	MailList. We have had a very promising offer from an individual in a *.org.
		- his org already runs list technology and their core business is
infrastructure
		- they are complementary, not competitive, to OASIS
		- they have long-standing and are likely to continue to have this
		- they could work through the xml.org domain name
	I therefore believe that the main question is whether X can find the same
amount of time as Henry to be ListManager and what happens if/when he
leaves the *.org. 

parallel activities
	We already have more than one threaded HyperMail (xml.org and e-groups) -
I see no reasons why these and others cannot develop in parallel. The same
is true of commentaries on xml-dev. I suspect that most of the ideas like
David Brownell's do not need formal permission from ListManager or
ListServer and individuals or groups are encouraged to develop them on the
list

Summary
	I think that some of the technical aspects can be outsourced attractively
and without cash costs. I hope that OASIS can find this a positive posting
and suggest how they can support some of it.

	Please be careful, courteous and constructive in your replies

	P.



***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************