Re: Update to draft-ietf-webdav-dublin-core

David, your reply makes me think that I did not make clear the distinction
between cases 1 ('monolithic') and 2 ('structured').  

It was a poor choice to use the term 'structured' for case 2, since the
'monolithic' approach is also 'structured/.  Maybe I should have called it
'individual'.  The distinction between the two is that in 'monolithic',
*all* DC  values are stored in one huge piece of XML, where in the
'individual' approach (case 2) there is one WebDAV property for each of the
13 possible DC values, but this property can contain multiple values.  In
case 3 (flat) there would be multiple WebDAV properties for a single DC
property.

case 1 is 1:N  WebDAV:DC
case 2 is 1:1  
case 3 is N:1

Before I go on, let  me ask whether I have at least managed to correctly
identify the three design alternatives (that is, there are exactly three,
no more, and these are the three)?  Then we can see what arguments there
are for each position.

That said, do you still feel that the 'individual' approach has the "huge
diasdvantage [that] In order to perform such updates within the property,
we will require new methods to express arbitrary XML structural changes."

Surely this objection applies to the monolithic approach even more strongly
than to the individual approach?

Your second objection seems to me that "some properties [can't be]
naturally expressed, if, ... they are already DTD-based and don't happen to
use <ol> and <li> to represent element containment and repetition."

I agree that if an application already has an existing XML representation
for its DC properties, then it might not be compatible with the one
proposed by Stracke, but surely this will be true no matter what
representation Stracke proposed?  There will always be someone, somewhere,
with a different DTD.  But surely converting from one DTD to another is
trivial, if the underlying ontologies are the same?  So I think your
objection is weak.

The alternative is to just store the DC property as a totally dead
property, and then how could you search it without knowing the structure?
The entire value of Stracke's proposal is to define a *standard* way to
represent DC in WebDAV, so we can, e.g. use DASL to query it.

best regards

Jim


------------------------------------
http://www.parc.xerox.com/jdavis/
650-812-4301

Received on Wednesday, 14 October 1998 12:13:23 UTC