RE: FOCUS: Properties section

Thank you Judy for your comments on the properties section.  My replies 
follow.

On Friday, August 01, 1997 2:30 PM, Judith Slein [SMTP:slein@wrc.xerox.com] 
wrote:
> 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.
>

The solution the design team has been advocating for handling property 
naming is to use URLs to develop names which can be used to prototype the 
properties, and get them into limited use quickly.  However, once a schema 
is well known, a URI scheme could be registered for it, thus gaining the 
benefit of registration of having a long-lasting (as long as IANA) unique 
name.

There was some discussion at Munich over the relationship between the name 
of a schema and the names of members of the schema.  Two camps of thought 
were observed:
Hierarchists: this group felt that property names should be in a hierarchy, 
and hence the Dublin Core schema name would be something like /dublin_core/ 
and the author entry would be a name like /dublin_core/author/ (lower in 
the hierarchy, but in the same hierarchy as /dublin_core/).
Relationists: this group felt that the schema names and the property names 
should be unbound.  A schema is modeled as a set in this view.  So, the 
Dublin Core schema would have the name /dublin_core/ but the schema would 
be a set, including /generic_properties/author/, /dublin_property/owner/, 
etc.

It seemed that the relationist view was slightly more flexible, since it 
allowed for the reuse of properties in multiple schemas.

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

A fine point.  In Munich it was decided to no longer support the ;DAV/ 
parameter, or the URL munge that accompanied it.


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

The rationale in favor of a flat namespace for properties is that it is 
much easier to support this for database implementations (and also makes 
for easier-to-specify methods, which registers high on my KISS meter :-) 
 However, I agree that hierarchical properties have lots of advantages.  I 
suspect that the flexibility of XML which allows extra tags to be included 
in an XML document will allow additonal versioning information (n the form 
of XML tags) to be added to is-derived-from relationships, and hence 
satisfy the need to define information on the links for versioning.  It's 
not as rich as hierarchical properties, but it should suffice our needs.

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

Perhaps this isn't clear in the spec., however the conceptual model of 
properties is that each property is an individual instance.  Hence, if the 
server is performing a storage optimization by linking several property 
instances to a single storage element, it is up to the server to deal with 
the consistency maintenance issues.  I don't think this is a protocol 
issue.

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

Attribute values are now retrieved by performing a schema discovery.

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

After Munich, ;DAV/ is no longer supported, but there will be a method 
which can retrieve the names of all properties on a resource.

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

Good point, this should be clarified. Only one instance per name.

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

Good point, this needs to be clarified.

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

Agreed, and also whether they should be performed atomically.

>
> See the discussion of DELETE above.
>
> In 2.6.3.2, Insert should not be listed as a possible value.

Good catch.

>
> 7. the syntax and semantics of SEARCH (Section 2.6.5)
>
> SEARCH should be renamed to something like "GETPROPS", which is less 
misleading.

This was agreed upon at the Munich meeting.

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

How might this be done?  I think the type of the link might convey enough 
information.

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

Agreed, this section needs a little clarification (frustrating -- we really 
have been through this spec. a number of times catching errors, honest :-)

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

Yeah, this TBD definitely needs to be fleshed out.

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

At Munich the attributes of properties were decided to be something the 
server set, and hence a client could not set a property attribute, and must 
discover property attributes by performing schema discovery (which is 
neatly still TBD ;-)

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

This is what is called a live property, although your point made at Orem 
that this distinction is not as strong as we thought is still valid.

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

I'm torn on the issue of human-readable names for properties.  On the one 
hand, clients which know about a property probably know the URI of the 
property, and hence would know how to display it to their users.  On the 
other hand, a client which allowed you to discover the properties defined 
on a resource might not, and would benefit from the human-readable name. 
 However, if we provide a human-readable name, then we need to provide that 
name in multiple character sets, which adds a lot of overhead to sending 
the value of a property.  Perhaps a series of human readable names could be 
retrieved during schema discovery.

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

OK.

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

Agreed.  In 1-2 drafts we should have a dramatic reorganization to pull 
methods, headers, and the dav schema together into one section apiece to 
more closely match the organization of the HTTP/1.1 spec.

- Jim

Received on Tuesday, 19 August 1997 21:20:14 UTC