- From: Dennis E. Hamilton <dennis.hamilton@acm.org>
- Date: Thu, 4 Oct 2001 22:57:10 -0700
- To: "WebDAV Working Group" <w3c-dist-auth@w3.org>
Me again! I have been lurking (well, cowering) while wondering exactly what is called for in terms of WebDAV Property Registrations. Although my search for relevant materials in the WebDAV archives is incomplete, here is how it looks to me: A. IDEAS FOR SOLUTIONS 1. There are ideas about how to store information about properties. 2. There are ideas and some effort on how to store property information in a database or similar collection. 3. There are ideas about marshalling property values that might have crossover to the description of property values. There are also ideas about constraints on property registration (e.g., it should be simple, not require central authority, etc.). There are also existing metadata description, interchange, and repository standards which might have to be accommodated in some way. B. WHAT PROBLEM IS SUPPOSED TO BE SOLVED? What I haven't found is the community thinking on *WHY* one would register properties, what would be registered, and who would use it (people and machines), and for what. That is, what problem(s) is property registration intended to solve, and is there consensus on the problem set? I invite discussion at this level before going too far into formulating an approach. C. A REQUIREMENTS SURVEY Here are survey questions. I've sketched characteristics of a property registration scheme in terms of end-to-end use (registrant to user). Please say what you consider required and what you consider unnecessary, along with any other thoughts you have. I will distill a requirements sketch from the responses and echo the key ideas for further consideration and refinement. I am not being rigorous about requirements versus constraints and solutions. I haven't looked for metrics on satisfaction of requirements. I'm probing for informal use cases as a point of departure for now. - - - THE QUESTIONS - - - D. REGISTERING A WEBDAV PROPERTY 1. Registration identifies the property and the authoritative source of further information? The source is located by URI? The source is located by non-Internet means? Is it necessary to associate a property with some authority over its definition? The authoritative source and the property are identified independently? 2. Does the registration make available a definition of the property? Is the definition amenable to human use? Mechanical usage? Both? In combination? What purpose is served by making the definition available? 3. Is the registration information submitted to third parties for retention and retrieval by anyone who chooses to discover the established use of the identified property? Might it be found on WebDAV servers that support the property? 4. What groups of people (by rôle) are required to be able to create and submit/register property-registration information? (This is distinct from being able to configure a server and/or client to support such a property.) E. USING REGISTRATION INFORMATION 1. Are property registrations intended to be useable by clients while interacting with a DAV server that supports a particular property? 2. If a property can be set by a client (even if live), does the property registration provide a. format conditions (syntax) for the value of the property? b. descriptive or other information with regard to the semantics of the value? c. indication of interdependencies with other properties? I think the key question is how far should the property description go to equip a knowledgeable person, in conjunction with flexible client software, to be able to specify a value for the property that (i) will be accepted by the server and (ii) is appropriate in the context of the semantics of the property? 3. Is it important to provide, in the registration information, customization descriptive presentations for users who are competent in different native languages? 4. How important is it to have the property-registration information provide sufficient information so that an user can intelligibly interpret a value for that property as presented by a flexible client? (By flexible is meant a client that allows use of properties other than ones it was specifically designed to accommodate.) 5. What groups of people (by rôle) are required to be able to find and use property-registration information? 6. Is property registration information to be attractive for configuration of a server to support the property (apart from mapping to an implementation and recognizing that no DAV server is required to support such an approach)? F. INTERCHANGE OF PROPERTY-REGISTRATION INFORMATION [This seems to be all about constraints. Ah well ...] a. Should the property-registration information be in a structured, mechanically-processable form? b. Must the property-registration information be easily rendered for human comprehension and review? c. Should property registrations be a resource type for storage in DAV itself? An existing resource type? d. How easy must it be to carry the property-registration information in plain text, in files, and in simple serial data streams? Embedded in structured information? -- Dennis Dennis E. Hamilton AIIM DMware Technical Coordinator ------------------ mailto:dennis.hamilton@acm.org tel. +1-206-932-6970 http://www.dmware.org cel. +1-206-779-9430 ODMA Support http://www.infonuovo.com/odma
Received on Friday, 5 October 2001 01:57:15 UTC