- From: <jamsden@us.ibm.com>
- Date: Wed, 3 Mar 1999 16:50:34 -0500
- To: w3c-dist-auth@w3.org, ietf-dav-versioning@w3.org
The WebDAV protocol supports a number of functions including collections, properties, namespace management, and soon to come, ordered collections, references, versioning, parallel development, configuration management, and searching. However, in spite of all these functions, client applications often want more. For example, a typical document management application might do document life cycle management functions like review and approval cycles, document states and transitions, rendering variants in multiple document formats, workflow and groupware functions, notification, publishing, etc. These client applications can exploit new resource types and WebDAV properties to implement these functions, but unless multiple client applications implement them the same way, interoperability is compromised. We could extend WebDAV to include all these capabilities, but then the protocol would get very complex, take a long time to develop, and include too many domain specific concepts what would not be reused for other domains. So how do we support new functions, promote interoperability, and keep the protocol domain neutral and simple? One approach is to take a lesson from XML. XML is a standard language for tagged documents. The standard specifies (among other things) that an XML document contains elements which have attributes and can contain other elements. So XML, unlike HTML, defines a standard syntax for documents, but not a standard for their specific content structure. A class of documents can be described using a Document Type Definition (DTD) that specifies the valid element structure for that class of documents. A DTD defines a "document language" that can be used to describe and validate documents that conform to that language. Interested industries can get together and define a document language for their industry. Then applications interoperate at two levels: one using XML documents as a common interchange format, and another using agreed upon DTDs to describe the structure of these documents. XML doesn't have to change to support Health Care or the Automotive Industry, those industries just have to agree on their respective DTDs. There are standards efforts underway to facilitate the construction of these DTDs. For example: - CDF for push applications - CIM2 for systems and network management apps - EAD for apps which need access to archival inventories and registers - HTML4 for Web documents - MathML for mathematics - OAG for supply chain applications - OTP for eCommerce applications - PGML for graphics - RosettaNet their catalog DTD for use in eCommerce - SMIL for streaming media apps - vCard for applications needing to process an electronic business card - WML - for transcoding applications to wireless PvC devices - iCal - for calendar and calendar-related events There are also web sites that provide a repository for DTDs so that interested parties can see what other people are doing in the same domain, and can locate potential collaborators. See http://www.schema.net. We could do something similar for client extensions to WebDAV based on resource types and properties. This could be facilitated by establishing a web site that WebDAV client developers could visit and contribute to that would contain proposals for properties and resource document types to support particular domains. For example, one could envision a consortium of document management providers who would collaborate on resource types and properties to support document life cycle management as described above. This would allow client providers to establish standards without extending the WebDAV protocol for particular domains of interest while still enabling interoperability. Client applications could continue to add value of their own, but could expect that documents conforming to the standard would have expected properties and structure. I propose that we establish such a web site, and that the WebDAV working groups may want to exploit this concept themselves instead of adding a lot of DAV properties to the standard that may prove to be too domain specific for general reuse, or result in too may server options for clients to be effectively written.
Received on Wednesday, 3 March 1999 16:58:55 UTC