- From: Jim Davis <jdavis@parc.xerox.com>
- Date: Thu, 21 Jan 1999 18:22:38 PST
- To: "Alex Hopmann" <alexhop@microsoft.com>
- Cc: w3c-dist-auth@w3.org
Alex, some comments on your internet draft, organized by the section number. Some of these are clarifying questions, some are just glitches, and are substantive. section 2, paragraph three, says This document follows the same collections as the WebDAV protocol specification [1] for defining these properties. The word 'collections' should be 'conventions' The subsections within this section are numbered from 1.2 but should be from 2.1 1.2 childcount Does this include hidden? The definition should explicitly say it does. I am puzzled by the three 'count' properties. you have childcount == count all children objectcount == count all children that are not folders visiblecount == count all children that are not folders or hidden The count of folders is childcount - objectcount, right? right? One criticism I have of all these countings is that it seems hard to generalize. Likewise, there are some things one can't count, such as the number of non-hidden objects of any type. Would it perhaps be better to define a generalized "partition" of the collection members, so you could slice it up in multiple, nested ways? Here's a sketch of how to do that <!ELEMENT division count name? partition*) > <!ELEMENT partition division+?> <!ELEMENT count PCDATA> <!ELEMENT name PCDATA> A division has a count, an optional name, and an optional set of partitions. Here, a name is just a string. (You might prefer it to be a propertyname or even a (boolean valued) expression. I don't care.) The name is intended to serve the same purpose as the isstructuredocument property, it's a hint to the UI about how to display the thing. Simple example. A collection with 17 members, of which 12 are folders, and the rest are something else <division> <count>17</count> <partition> <division> <count>12</count> <name>folder</name> </division> <division> <count>5</count> </division> <partition> </division> Since the sum of counts of the divisions of a partition must sum to the count of the containing division, the final (none of the above) division may be omitted, so we can write the above as <division> <count>17</count> <partition> <division> <count>12</count> <name>folder</name> </division> <partition> </division> Same collection, with 17 members. The 12 folders are further partitioned into 5 'special' folders, 2 'reserved' folders, and the remaining five are just 'generic' folders. <division> <count>17</count> <partition> <division> <count>12</count> <name>folder</name> <partition> <division> <count>5</count> <name>special</name> </division> <division> <count>2</count> <name>reserved</name> </division> </partition> </division> <partition> </division> Same as above, with two alternate partitions of the seventeen members. The first one is based on the folder/non-folder distinction, the second on the hidden/non-hidden distinction. <division> <count>17</count> <partition> <division> <count>12</count> <name>folder</name> <partition> <division> <count>5</count> <name>special</name> </division> <division> <count>2</count> <name>reserved</name> </division> </partition> </division> <partition> <partition> <division> <count>2</count> <name>hidden</name> </division> <partition> </division> You could also express this with only one top level partition (folder/non folder) where each of its two divisions was then divided by hidden/non-hidden. 1.3 defaultdocument Is this supposed to define what GET on a collection returns? If so it should say so. Must the resource identified by defaultdocument be an (immediate) member of the collection? 1.4 id Would a weak etag suffice for this purpose? If a resource is copied (not moved) must the copy have a different id? If so, then how do you MOVE, sinnce MOVE is COPY plus DELETE. And likewise, how could I use the id for replication? On the other hand, if a copy kept the id, then if you edited one copy and not the other, you'd have two different resources, with the same ID but different contents. On the other hand, since you don't change the ID when you edit the resource, this could happen anyway (given a caching proxy) 1.5 isfolder The DTD for this item defines ishidden not isfolder Why can't you make this a "subtype" of the DAV:resourcetype property? <collection></folder></collection> 1.6 ishidden The text Description says "If this property is absent, the collection is not hidden." the word "collection" should be "resource" 1.7 isstructureddocument Why not use dav:resourcetype for this? <collection><structured/></collection? The Purpose referers to the "iscollection" property, which is undefined. (typo) missing a newline before the Definition 1.8 hassubs would be better named "hassubfolders" 1.9 nosubs Perhaps a better name is "contraception" or "sterile" since the meaning is that one can't create any more children. Hmm, that's a bad plan, it would make the republicans not want to fund WebDAV. Okay, how about instead "nocreatechildren"? or even "dontmkcol". Otherwise it's too easy for people to confuse this with meaning "this collection has no subfolders" 1.10 objectcount does this count hidden items? 1.11 reserved Could a plain (non collection) resource also be reserved? Can one do a PROPPATCH on a reserved collection? Can one do an ORDERPATCH (from the Advanced Collection Resources draft) Would a printer queue be a good example of reserved? 1.12 visiblecount The definition DTD is for 'reserved' not 'visiblecount' I'd like to suggest an additional property, "ispaged". If this property is true of a collection it means there is a one to one correspondance between the children of the collection and the 'pages' of a document. So for instance, if you scanned a document into a collection of TIFF files, that collection would have the ispaged set. Or if you saved a powerpoint file into HTML, creating one HTML resource for each slide, that would also be paged. If the collection is ordered, as in ACR, then the collection ordering corresponds to the page ordering. best regards Jim Davis
Received on Thursday, 21 January 1999 21:23:01 UTC