RE: PropReg: Probing for Property-Registration Requirements

Thank you Dennis for taking the lead on the issue of property registration.
Your set of questions is excellent -- they made me think about several
issues I hadn't considered before, and do a good job of exposing the
complexity of property registration.

Let me take a whack at answering these questions to get discussion rolling.

> -	-	-	THE QUESTIONS   	-	-	-
>
> D.	REGISTERING A WEBDAV PROPERTY
>
> 1.	Registration identifies the property and the authoritative source of
> further information?

Yes to both. Registration identifies the property (its "name", which
includes its "namespace") and the human organization or person to contact
for further information.

>  The source is located by URI?  The source is located
> by non-Internet means?

Since *people*, often working within some organization, define properties, I
would expect the contact information to be a person, and their
organizational affiliation at the time they defined the property.

> Is it necessary to associate a property with some
> authority over its definition?  The authoritative source and the property
> are identified independently?

I think it would be a good thing to identify which person or organization
has change control over the properties. In the case of a standards
development organization (SDO), it may be the case that a specific working
group developed a property, but the SDO as a whole has change control (since
the WG may go away long before the end of the lifetime of the property).


> 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?

In my view, the ultimate purpose of the registration is to enhance
interoperability of these properties. There are multiple consumers of
property information: system designers, end users, and computational agents
(i.e., programs, such as a client or server implementation). A good
definition satisfies all consumers.

There are a couple of aspects to each property definition:

* A human-readable description of the property contents ("what" does the
property contain?")
  ("The property will record the address of the copyright holder of the
resource")

* A human-readable description of some expected uses of the property ("why"
might someone use this property)

* The machine-readable syntax of the property. This includes the XML DTD, as
well as the syntax of the contents of each XML element and attribute used.
  ("The property MUST start with an <address> XML element, defined with the
following DTD, with the following sub-elements (and their definition) ...").

* The semantics and standard schemas used for the contents of the property.
  ("For addresses in the United States, the <state> XML element MUST have a
value that corresponds to one of the postal state codes defined in ...")
  ("The value of this field is unconstrained...")

* Is the property live or dead? Writeable or protected? ("how" does a client
interact with this property?)

* Does the property form part of a protocol?
  ("typically a client should write property X, then read property Y...")


It is my opinion that the current state of the art is not far enough
advanced that providing *only* a machine-readable definition of a property
is sufficient. That is, while a definition in a language like RDF Schema
would be helpful, if available, such a definition does not, by itself,
provide sufficient information to a client developer to understand and use
that property.


> 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?

Registraion information should be submitted to an organization that is
expected to be long-lived (~25+ years) and that has, as part of their
mission, archival storage.

Property registration information should be retrievable by anyone on the
Internet without fee. Unless previously copyrighted, people submitting
property information should make it available under standard IETF copyright
policy.

Patents and copyrights that apply to properties themselves, or to the
contents of properties, should be noted in the registration of the property.

Just as most HTTP servers do not have a copy of RFC 2616 available on the
server, there should be no expectation that servers implementing a specific
property will have a copy of the registration information on that server.

> 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.)

Anyone should be able to submit property registration information.

It woould be useful to have a low-overhead vetting process, to ensure that
property registrations are of reasonable quality, and address all issues.
MIME types in the vnd. tree are sent to a mailing list, and typically
receive feedback within a few days. The entire registration process
typically takes under two weeks.

> 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?

No.

> 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?

It should provide sufficient information that a developer, working from the
property description alone, can implement a client or server using the
property, and have reasonable assurance that their implementation will
interoperate with other implementations of the same property.

It should also provide sufficient information that an expert end-user, when
presented with the value of this property, can understand it.

> 3.	Is it important to provide, in the registration information,
> customization descriptive presentations for users who are competent in
> different native languages?

Well, in general I think we need to provide more guidance on i18n of
properties.

The best approach here would be to develop a specification giving guidance
on how to handle some common i18n scenarios with properties, and then have
the property registration identify which of the common mechanisms it is
using.


> 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.)

It would be nice if the property registration gave some suggestions on how a
user interface should present the value of the property. This is especially
useful for properties with RDF values.

I believe the property registration should describe the property well enough
that an expert end-user can understand the value of the property. I'm shying
away from a more expansive definition that would be sufficient for "most"
end-users, since this might involve giving background tutorials on the
nature of metadata itself, background on the nature of the problem the
metadata schema is addressing, etc.

> 5.	What groups of people (by rôle) are required to be able to
> find and use property-registration information?

All developers and end-users should be able to find and use property
registration information, if they desire. However, the presentation of
property registration information should not be a requirement on
implementations.

I liken this to the RFC series. Developers are by far the primary consumers
of the specifications. But, it is often the case that sophisticated
end-users and students have an interest in reading the specifications to
have a deep understanding of the techology. Certainly no HTTP browser
provides the ability to read the HTTP specifications.

> 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)?

Server configuration strikes me as out-of-scope, since it will vary widely
by server.

> 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?

I view this as a bonus, not a requirement.

> 	b.	Must the property-registration information be
> easily rendered for human comprehension and review?

Yes. I view humans as the primary, and most important consumers of the
registration information.

> 	c.	Should property registrations be a resource type
> for storage in DAV itself?  An existing resource type?

I see no need to define a new MIME type, or DAV resource type for these
registrations.

> 	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?

I view this as being very unimportant.

- Jim

Received on Friday, 5 October 2001 14:22:05 UTC