- From: David G. Durand <dgd@cs.bu.edu>
- Date: Fri, 9 Oct 1998 23:38:14 -0400
- To: WebDAV WG <w3c-dist-auth@w3.org>
- Cc: Meta2 Mailing List <meta2@net.lut.ac.uk>
At 1:04 PM -0400 10/8/98, John Stracke wrote: >"David G. Durand" wrote: > >> If it supports no such feature, we have already lost searchability of >> multiple valued Dublin attributes anyway, since only signle values will be >> effectively searchable at the server end. > >But this applies to any structured DAV property. The DASL group has discussed >the possibility of searching structured properties, and (as far as I can >tell) has not given up yet (there's a proposal on the table from Alan, >though I >don't see any responses on the list). Exactly. If there's a general searching mechanism that can solve this, it could search a monolithic property as easily as a multiple-valued property. I like Larry's arguments for separate properties for each DC item, but I still worry about the multiple value problem, especially in conjunction with nesting properties (since there may be multiple values at several levels, flattening to a single level of properties still seems hard, and error prone. >But this will make things even less searchable, and much less manageable. > >> This is actually rather unpleasant: the use of ordered list tags from >> another DTD to indicate multiple values is a pretty serious case of tag >> abuse. > >What's wrong with defining <ol> in a property (or at least a Dublin Core >property) to have the meaning we need? Nothing in itself, it's just that choosing an unnatural name seems silly to me. ol and li have widely accepted meanings, and I don't see that we get very much by punning on the HTML tags. >> or we start needing to store parallel synchronized lists in different >> properties, which is a pain for clients, and harder for servers (and pretty >> much requires a big implementation, as it won't work with simple dead >> property storage, which seems pretty bad to me. > >I disagree--the DAV server just sees them as separate dead properties; it >doesn't >have to know that there's any relationship among them. >> This solve the property naming problem, but not the fact that we need a way >> to synchronize several such values into a single creator. > >OK, here's your straight line: Why? > Any way that relationship is maintained it's going to be error prone to determine how they relate: we can't assume, for example, that the various sub-elements of a multiply occurring item like Creator are even all present, so if they are stored on separate properties we either need a way to note how they correspond, or use explicit null values for any unspecified properties, so that the various lists are all the same length. Enforcing this kind of parallel list structure across multiple properties seems very clumsy as a client-managed operation (they must all be locked to make an update), and hard to implement on the server side. Example: <creator><firstname>Joe</firstname></creator> <creator><lastname>Botticelli</lastname></creator> This two-creator set of names does not flatten well, as we get (naively) the following properties: creator.firstname = <ol><li>joe</li></ol> creator.lastname = <ol><li>Botticelli</li></ol> but there is not 1 creator "Joe Botticelli" So we can go instead for something like this: creator.firstname = <ol><li>joe</li><li></li></ol> creator.lastname = <ol><li></li><li>Botticelli</li></ol> any update to any creator tag must lock and update all properties of the form creator.* or we could have: creator = <creator><value><firstname>joe</firstname></value> <value><lastname>Botticelli</lastname></value></creator> This of course, is just 1 step flatter than putting the whole DC thing on one property. For simple seraching this might be worth it, but I think that any further flattening of a hierarchy is going to be vary hard to make work in a flat namespace like DAV properties. In anything that works well for hierarchically nested items, some search smarts are going to be needed for effective retrieval. So I think that the best idea may still be putting the whole meta-description in one property, or splitting only the top level. In other words, I am sensitive to the notion of why splitting the properties makes some sense, but I'm not convinced that it will work very well. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://www.dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________
Received on Friday, 9 October 1998 23:30:40 UTC