RE: FOCUS: Properties section

Jim requested comments on the property section of the WEBDAV draft, so let
me get that discussion going:

1. the use of URIs for property names (Section 2.2.2.3)

I support having a property name be a URI that refers to a resource
containing definitions of the syntax and semantics of the property.  This
could also be the place where a human-readable property name and description
are stored.  This will be a valuable way for authors to share the same
properties and property schemas.  If RDF develops as anticipated, it will
make available a standard way of defining properties, that servers could use
to enforce the syntax and semantics of property values.

There are, however, several of disadvantages of this approach that are worth
considering.  First, the lifetime of a property name should be very long,
much longer than the lifetime of the average Web site.  Second, we want to
encourage people to use the same properties, not encourage a proliferation
of properties, as the use of URIs as property names may do.  Third,
properties are often interdependent, so we want to encourage people to make
clear the relationships between properties.

I don't know what to do about the first of these, other than urging site
administrators to be responsible about keeping property definitions
available when servers are retired.

The second and third of these problems could be helped by naming property
schemas. I assume that if a property belongs to a schema like Dublin Core,
there could be a URI that references the definition of the schema, and URIs
pointing inside that schema definition to reference definitions of each of
the properties it contains, like

http://server1/dublin
http://server1/dublin/Subject
http://server1/dublin/Title
etc. 

2. the encoding of URIs to create names which can be used with GET and
DELETE (Section 2.4.4)

While HTTP just recognizes resources, we are introducing three new classes
of resources: properties, collections, and version history collections.  We
are introducing some new methods that operate on new classes of resources,
and restricting the way existing HTTP methods apply to them.

I think that we should provide a single consistent way of determining which
type of resource a URL refers to.  At the moment we use the ;DAV/ parameter
to indicate a property, and the IsCollection property to indicate a
collection.  Presumably there will be some way of determining whether a
resource is a version history collection.  Whatever mechanism we use should
also be extensible so that new kinds of resources can be distinguished in
the future.

From the outset, there has been strong resistance within WEBDAV to encoding
information in URLs that would have to be parsed out.  This was especially
true in the discussion of version ids.  How is what we are doing here any
different from putting a version id into a URL?

3. the flat namespace of property names (Section 2.2.2.3)

For ordinary properties, a flat name space is probably acceptable.  I don't
know of document management systems that allow properties to have
properties.  The examples I have been able to think of where you might want
properties of properties would probably be cases of "large chunk metadata",
where the property is a separate resource linked to the resource it
describes.  For example, you might have a resource that is a video, and a
property that is a review of the video, which itself has an author and a title.

However, there are two sorts of cases that make me think it would be a
serious mistake to enforce a flat property space:

It's particularly dubious because we are treating links as properties.  The
edges of a graph are just as important as the nodes, and just as likely to
need to hold properties.  The issue of the link between a version and the
version history needing to have properties has already come up.  So either
don't treat links as properties, or allow properties to have properties.

In addition, we already think we may need to provide access control on
properties.  One approach to implementing access control is through
properties on the resources to which access is being restricted.  We'll be
ruling this approach out if we say properties cannot have properties.

4. the requirement that the value field for properties be XML data
(implied, but not explicitly stated)

No opinion

5. the semantics of HTTP/1.1 methods (GET, DELETE, PUT) applied to
properties (Sections 2.6.2, 2.6.1, and 2.6.4)

DELETE:  Questions arise both for DELETE and for PROPPATCH if it is possible
for many resources to share a single property value.  It might well be that
all resources on a given server have one of a small number of copyright
property values.  The server might want to store each copyright property
value only once, and have the copyright property URIs of many resources
point to each of those values.  Then we have to decide whether DELETE and
PROPPATCH/Remove mean delete the value from the server or remove the
property from the resource, but leave the property value on the server.

This situation is analogous to DELETE for external members of collections.

GET:  I assume, from the example, that you really want to say a GET on a
property returns the name and value of the property.  Also any related
attribute values?

The slide from Orem says that GET http://foo;DAV/ will return all properties
on the resource, but 2.6.2 does not say this.

PUT: I'm not sure I believe the rationale for saying that PUT must fail for
properties.  But it takes more expertise in HTTP than I have to decide
whether it makes sense.

6. the syntax and semantics of PROPPATCH (Section 2.6.3)

State explicitly that it is not possible for a resource to have multiple
instances of the same property.

If I try to do a PROPPATCH/Create for a property that already exists on a
resource, will it fail, or will it overwrite the existing property value?
(If I want to change the value of a property that is already present, must I
first Remove the property, or can I just Create it?)

If the server is required to perform the operations in a PROPPATCH request
in the order they appear there, that should be explicitly stated.

See the discussion of DELETE above.

In 2.6.3.2, Insert should not be listed as a possible value.

7. the syntax and semantics of SEARCH (Section 2.6.5)

SEARCH should be renamed to something like "GETPROPS", which is less misleading.

Actually, SEARCH as described in the specification seems to be some kind of
hybrid between SEARCH and GETPROPS that does not make much sense.  To sort
it out, you have to do one of two things:  Either make it GETPROPS by
restricting it so that it returns only properties of the resource named by
the request URL (in the case of a collection, it returns only properties of
the collection, not properties of any of its members), or make it SEARCH by
having the result set include the URL of each property value returned, so
that you can tell what resource the property belongs to.  What use is the
property list if you can't figure out the URL of any of the property values
returned?  

Unary AND and Unary OR operators are pretty weird notions.  

8. the encoding of links into XML (Section 2.5)

To repeat: Treating links as properties where properties have a flat name
space is very problematic.  The edges of a graph are just as important as
the nodes, and just as likely to need to hold properties.  The issue of the
link between a version and the version history needing to have properties
has already come up.  So either don't treat links as properties, or allow
properties to have properties.

It would also be useful to be able to tell whether a link is to a piece of
large-chunk metadata or to some other related resource.  That would enable
search engines to decide whether to follow the link and examine the
destination resource. I think this is not possible on the current model of
links.

That having been said, if we do treat links as property values: Section 2.5
needs to make link syntax more formal at some point.  The Description
section in 2.5.3 is helpful, but cannot be considered part of the formal
definition of a Link.  The Parent of the Link XML Element should be
Propvalue?  Or Property? The Values section needs BNF that shows that a
property value may be a list of links, that a link may have multiple src and
dest elements, that a link may have additional typing information beyond the
Propname.  It needs to show that the propname is part of the link value (if
it is).

Other Issues:

The draft suggests (2.2.4) that it will be possible to discover what
properties a server supports and whether it allows user-defined properties,
but I don't see a specification of how this can be done.  (There is
currently no requirement to be able to do this, though I personally think it
is very useful functionality for which we might want to add a requirement.)

Attributes of Properties

Does it make sense to decide whether an instance of a property is readonly
or live, or just to decide that all instances of a property on a given
server will be readonly or live?  I think the latter.  The server will
presumably decide this, not the client.  At least, this is true for servers
that support only a fixed set of properties, like the file system properties.

If a server supports arbitrary user-defined properties, it still seems to me
to make more sense for the server to treat all instances of a given property
the same.  If the user provides a formal definition of the property (once
RDF is available, for instance), the server might be willing to make any
property that has a well-formed RDF definition live.

So it should not be possible to specify attribute values when setting the
values of properties.

The spec does not say how to get the values of attributes for a given
property, and the examples of getting / searching for property values do not
show attributes being returned.  (The syntax of Prop does not show a place
for attributes.)

Behavior of properties on COPY: We need to recognize the following types of
properties:

o Server-mandated properties -- properties that the server requires to be
present.  The server may or may not provide the values for these properties,
and may or may not enforce syntax / semantics for the values.

o Server-maintained properties -- properties for which the server sets the
values. Maybe these are what the spec calls readonly?

Even if the Duplicate-Properties header is false, server-mandated properties
will be created on the new copy, and server-maintained properties will be
created and have their values set by the server on the new copy.  If the new
copy is on a different server, the new server will create whatever
server-mandated properties it wants.  This behavior should not cause a
failure of COPY or MOVE.

Human-readable name and description need to be available, and should
probably be returned with every property value.  The reasonable place for
them to live is with the property definition, but that might be off on
another server.  So what should we do?

Different Model

Maybe it would be good to return to the previous draft, where properties are
NOT resources.

It's confusing for properties to behave like resources in some ways, but not
in others, and for existing HTTP methods to have to behave peculiarly for
them.  If properties are not resources, we don't expect any HTTP methods to
work for them.

What are requirements for links:
        Links are the edges of a graph
        Links must be able to have properties
        For any resource, it must be possible to find out what links have it
as a source
        For any resource, it must be possible to find out what links have it
as a destination
        It would be helpful to be able to find out, for any link, whether
the dest is metadata describing the source
        Links are typed

Style and Organization:

It would be useful to put back all the background explanations that were in
the previous properties draft, but lost from this one.  (large chunk / small
chunk properties, properties that are in / on resources, etc.)

I think it would be much easier to understand the XML DAV schema if it were
all formally captured together in one place, and referenced as needed.  This
would make it easier for a reader (particularly an implementor) to see
relationships between elements of the DAV schema, and for the authors to
confirm that they have formalized all the relationships between elements
that are needed.



Name:			Judith A. Slein
E-Mail:			slein@wrc.xerox.com
Internal Phone:  	8*222-5169
External Phone:		(716) 422-5169
Fax:			(716) 265-7133
MailStop:		105-50C

Received on Friday, 1 August 1997 17:26:21 UTC