Re: property value clarification

A little clarification here. I knew this was a sticky issue and is
obviously raising some good discussion, but my main question related to
the properties associated with the property-name elements, rather than
the internal markup.

If you want to use properties INSIDE, then I'd think that is fine. The
main question revolved around whether the attributes of a property-name
element are considered part of the value that must be persisted.

<prop>
  <propname>contents</propname>
</prop>

We save all attributes on markup within the "contents", but what about
attributes on the "propname" element?

So far, I've heard "implementation defined [since we'll omit it in the
spec]" (although I'm not sure I read EJW's response right), and that if
an xml:lang attribute is present, then it must be persisted.

There have also been some ruminations about namespace handling; in
particular, whether the server might rename the prefixes that are used.

IMO: only the contents and its markup are property values. Namespace
prefixes may be rewritten at will by the server (based on the
requirement that it is well-formed XML, then I believe we can assume it
is allowable to manipulate it as long as the well-formed-ness and
semantics are maintained). I don't know enough about xml:lang to
comment.

-g

David G. Durand wrote:
> 
> At 11:42 PM -0400 10/29/98, Jim Davis wrote:
> >At 03:56 PM 10/29/98 PST, Jim Whitehead wrote:
> >>...My sense of the working group is there does not currently exist any
> >>consensus on this topic.  Nor, given the depth of the issues, is it likely
> >>that any consensus could be achieved quickly.  My recommendation is to leave
> >>this issue unresolved, and be silent on this topic within the spec.
> 
> It's not at all clear to me that one can do that:
> Either you are allowed to put arbitrary XML in properties, or you are not.
> If you are not, then that should be specified (and we could relax the
> restrictions later). If you are, then servers must choose _some_
> XML-preserving implementation (perhaps literal storage of the string, or
> portions thereof).
> 
> One of the "properties of properies" is that people can make them up to
> solve their representational problems, and so they need to know what the
> syntax is).
> 
> >I concur, with one exception, namely the xml:lang attribute.  This
> >attribute must be recorded in order to provide international support.
> >Otherwise there is no way to do correct equality comparisons on properties.
> 
> >I asked specifically about this attribute in email on 7/27, the sole reply
> >(8/5, from EJW) indicated that it would be preserved.
> 
> >It's very important that this attribute be preserved, otherwise DAV is
> >limited to English language values only.  (Or to be more precise, you could
> >store non-English values, but you couldn't operate on them reliably.)
> 
> Right, this is one of many. Jim's example about namespaces is another case:
> and it's also a case where serer rewriting is _only_ appropriate if the
> client and server are both assumed to have XML processors.
> 
> I don't think that XML data handling is so hard that restricting it is
> worthwhile.
> 
> One table "other_attributes" with columns "attname", "elementreference" and
> "value" will handle any number of arbitrary attributes, even in a
> relational system.
> 
> >But as for all other attributes, I recall Yaron saying that the WebDAV data
> >model is *not* XML, rather XML is merely one (of possibly many) on the wire
> >transport encodings for WebDAV values.
> 
> Fortunately that's not _in_ the standard, is it? The standard defines a
> protocol, not a data model. The protocol either allows XML properties, or
> some undefined subset of them. The latter is bad (unless we define the
> subset) and the former says nothing about how properties must be stored in
> the engine.
> 
> >If this is indeed the concensus opinion, then  WebDAV is not obligated to
> >support every feature of the XML data model.  It is XML that is at the
> >service of WebDAV, not the other way around.
> 
> That's fine, but if you're going to use the syntax, you need to say
> something if parts of that syntax are potentially ignored by servers!
> 
> Frankly, accepting full XML properties seems like a no-brainer to me: the
> parsers are small, and the data model is simple. (RDBMs are going to have
> much more trouble handling nesting than they ever will with attributes).
> 
>    -- David
> 
> This supports Jim Whitehead's assertion that there is no consensus, but
> denies that this is acceptable. If we want to outlaw all attributes other
> than a small fixed set, that is OK, though I'd be surprised if anyone can
> present an argument as to how that makes a significant savings.
> _________________________________________
> 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                    \__________________________

--
Greg Stein (gstein@lyra.org)

Received on Friday, 30 October 1998 08:49:38 UTC