RE: FOCUS: Properties section

At 06:14 PM 8/19/97 PDT, Jim Whitehead wrote:

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

OK, I'll be watching to see whether the syntax we define for links allows
additional information to be attached to them.  How flexible can this be?
For versioning, maybe one site wants to attach a comment, editor's name, and
checkin date to the link between a version and a version history graph.
Another site wants, in addition, a version label, the employee id of the
author, team id, and an authorizing signature.  Other sorts of links might
need completely different sorts of data attached to them. An article
included in one anthology for use in a university course has a royalty
charge of .00 / page for retrieval, the same article included in a different
anthology intended for commercial sale has a royalty charge of $.15 / page.

I'll also be interested to see whether the syntax for properties allows
access control information to be attached to them.


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

I don't see how a search engine could be expected to look at the type of a
link and figure out whether it points to metadata or not.  But if it's
really true that links can have attributes, we could define an attribute
IsMetadata or IsSearchable as a hint to search engines that they are likely
to find useful data to index there.
>

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

So I'm still confused.  If "live" really means just that the server enforces
syntax / semantics, that's certainly true for properties where it is always
the server who sets the value (server-maintained properties).  But it could
also be true for properties for which clients set the value -- maybe there's
an expiration date property that has to be in a certain format and be later
than the current date.  The server can enforce the syntactic and semantic
rules even though it is the client that sets the value.  So "live" is not
synonymous with "server-maintained."


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

I don't see why you would retrieve the human-readable property names in all
available character sets, any more than you would retrieve all variants of a
resource.  You would retrieve just the one that's appropriate for the
particular client or user.

A few scenarios:

1. We're at a site where each resource must have a fixed set of properties
that belong to a single well-known schema.  If the client can find out that
this is the case, it might make sense for the client to retrieve the schema
definition (or at least the human-readable names from it) the first time the
user asks for properties from that site, and just keep the information
cached locally.  (This assumes that some group is going to standardize what
a schema definition is like, and that it's going to include a human-readable
name for each property.)

2. We're at a site where authors are allowed to put any properties they like
on their resources.  The properties are not required to be part of any
well-known schema. The user says, "Show me all the properties of resource R."  

2a. We could let this be a single GETPROPS request to the server, which
would return the names, human-readable names, and values of all the
properties on the resource. How will the server know which properties belong
to schemas and which do not? Assuming the server can figure this out, for
properties that do belong to schemas, the server could query the schema
definitions for human-readable property names.  For properties that do not
belong to schemas, the server might maintain a table of local property
definitions (including a human-readable name), or it might store the
human-readable names with the property value.

2b. Or we could make the client find out what properties are on the
resource, figure out which ones belong to schemas, and find the
human-readable names by querying the schemas or asking the server for
human-readable names of locally defined properties, as appropriate.

--Judy

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, 22 August 1997 09:48:59 UTC