PropReg: Probing for Property-Registration Requirements

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