Re: Updated agenda

In message <ae0752991f02100470fb@[]>, Jim Whitehead writes:
>At present, there are 15 confirmed attendees for the San Mateo meeting,

I'm sorry I won't be there.

But I'll try to get my two cents in via email here...

>Here is an updated agenda for the meeting

>Morning (9AM)
> - Introductions

> - Overview of efforts to date on distributed authoring

I suggest you put this overview before the business of defining
the group. Perhaps put the talks here too.

> - Discussion of the direction and purpose of the working group

Just to reiterate: it's not a W3C working group yet. For details
on how a W3C working groups works, see:

But that shouldn't stop us from using the w3c-dist-auth mailing list,
since it has a handy archive.

In particular, we have to nail down the following:

   1.The overall goal of the group; 
   2.Criteria for completeness of the group's work; 
   3.Deliverables with target dates; 
   4.Membership criteria 
   5.Expected amount of W3C resources which the WG will take to run; 
   6.Commitments from non-W3C staff upon which the running of the WG is

Here's my take on the above:
	1: make web editing as reliable as browsing, and nearly
		as ubiquitous
	2: the group is done when there's shared understanding of
		distributed authoring mechanisms in the development
		community and the market. For example, the top
		3 to 5 editing clients and servers all interoperate
		according to published specs.
	3: here's a guess:
		spec: "Considerations for authoring tool support
			in HTTP servers" (covering issues like
			Derived-From/Version, reliable PUT, etc.)
		code: server that supports the above (based on jigsaw)

		spec: "Editing Hypertext" (covering issues
			like re-writing URLs during cut/paste, save-as)

		code: client that supports the above (based on Amaya)

		spec: "On Link Maintenance in the Web"
			(covering things like linkmaps,
				server-to-server link maintenance protocols,
				and authoring tool support for redirects)
		code: client/server support for the above

	4: based on acceptance of a (short: one page) position paper
		from Jim and the rest of the group.

	5: W3C is probably in a position to contribute
		1/5 FTE Jigsaw engineer, 1/2 FTE Amaya engineer,
		plus supporting Jim W. as chair.

In particular, the Amaya group (led by Vincent Quint at INRIA) is
going to be the main W3C resource for this effort. Be sure to take
good minutes, since I won't be there, and we don't plan to have Henrik
do much of the follow-up work on this.

	6: 10 FTEs from each of the vendors :-) Just kidding... but
		please do be concrete (and generous!) about this part.

>Afternoon (1:30PM)
> - Identification of key areas in which existing systems are unable to
>interoperate (e.g., HTTP method employed to write contents, access control,

About access control: I see on the group page, I see:


The breakout session at WWW4 recommended not pursuing a common access
control scheme and interface across HTTP servers. This is a mistake.
Due to the importance of access control, and its centrality to the
content control process at many organizations, an access control
standard is one of the most important artifacts that should be
generated by this working group.

I suspect there has been a misunderstanding. We didn't agree that
there would be _no_ common access control _interface_: in fact, we
pretty much agreed that the interface would be a button that takes you
(by following a link constructed by convention from the page's address
ala the way NaviPress does it) to a form where you can do access
control administration. So a spec for that would be dandy.

But a common access control model? Will it be capabilities or access
control lists? This has been an open problem in distributed systems
for tens of years. It was the model in the server that we recommended
against persuing at WWW4. We don't expect to solve this long-standing
problem, do we?

> - Review of current distributed web authoring systems and the mechanisms
>they employ:
>   o Invited talk: Henrik Frystyk on Amaya, PUT model
>   o Invited talk: Dave Long on GNNpress/GNNserver
>   o Invited talk: Andy Schulert on FrontPage

As time is short, I would like folks to concentrate on the
_differences_ between the systems, and in particular: the non-standard
features/mechanisms in the systems.

At the WWW4 break-out, we were able to triage the features fairly
quickly into:
	(a) those that don't interfere with interoperability
		and should remain features to compete on
	(b) mechanisms that aren't covered by the standard, but
		should be
	(c) mechanisms that _are_ covered by the standard, but
		couldn't be used in practice due to limitations
		in the installed base of cruft... er... software.

Experience reports about particularly tricky parts of implementing the
standard is really valuable as "advice to implementors" as well --
after all, we're after reliability in practice, not just a nice spec.


Received on Tuesday, 9 July 1996 09:23:36 UTC