Re: AW: Issue: XML_LANG_CLARIFY

I agree with Julian that

"just saying that RFC3076 (Canonical XML) applies (thus persisting *all*
attributes on the property elements in
addition to inherited attributes from the XML namespace) would make the
*specification* simpler and more logical."

I believe that is what the client would expect and I believe that it is
easy enough for servers to implement.

Regards,
Tim

----------------------------------------
"Julian Reschke" <julian.reschke@gmx.de> wrote:

Geoff,

Canonical XML specifies the inheritance behaviour for all attributes in the
XML namespace, that is with a namespaceUri of
http://www.w3.org/XML/1998/namespace, so what a server needs to do is to
check the namespace, that's all. There's a reason why the W3C is defining
things like this -- if WebDAV is going to define it's own rules, it would
better add a rationale to define why...

In my proposal in


http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0102.html

I've tried to write down what seems to be the current consensus (no
attributes except xml:lang), although just saying that RFC3076 (Canonical
XML) applies (thus persisting *all* attributes on the property elements in
addition to inherited attributes from the XML namespace) would make the
*specification* simpler and more logical.

Julian

-----Ursprüngliche Nachricht-----
Von: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Clemm, Geoff
Gesendet: Mittwoch, 25. April 2001 23:18
An: WebDAV WG
Betreff: RE: Issue: XML_LANG_CLARIFY


   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   I don't see any advantage as long as the inheritence rules are clearly
   specified, such as in

   <http://www.w3.org/TR/2001/REC-xml-c14n-20010315#DocSubsets>

This doesn't help a server that encounters an attribute type that it
doesn't understand (for example, a custom attribute or an attribute
introduced since that server was written).  If we only allow
attributes on the property node and below, a server can at least save
and return those attributes.  If we allow attributes on the DAV:prop
node, the server would need to know the inheritance characteristics of
that attribute in order to know how/whether to persist it.  I don't
think we want to just say "all attributes are inherited".

We could make an exception for xml:lang, but I don't see a compelling
benefit for doing so (I'm not saying there isn't one, but rather
just that I don't see it).

But whatever we do with xml:lang, I believe we should say something
in general about the handling of attributes on DAV:prop nodes
(saying there can't be any is about the simplest thing we could
say :-).

Cheers,
Geoff

   -----Ursprüngliche Nachricht-----
   Von: w3c-dist-auth-request@w3.org
   [mailto:w3c-dist-auth-request@w3.org]Im Auftrag von Clemm, Geoff
   Gesendet: Mittwoch, 25. April 2001 22:47
   An: WebDAV WG
   Betreff: RE: Issue: XML_LANG_CLARIFY


   To keep things simple, I would just disallow the xml:lang attribute
   on the D:prop node.  In fact, I would indicate that all attributes
   on the D:prop node are ignored unless explicitly defined by the
   protocol as being allowed there.

   This allows a client to ignore attributes on the D:prop node, and
   just store all attributes on the property node, without having to
   understand the inheritance semantics of those attributes.

   Cheers,
   Geoff

   -----Original Message-----
   From: Jason Crawford [mailto:ccjason@us.ibm.com]
   Sent: Wednesday, April 25, 2001 3:44 PM
   To: Clemm, Geoff
   Cc: WebDAV WG
   Subject: RE: Issue: XML_LANG_CLARIFY




   To be persistant, I think we all agree the xml:lang attribute can be on
the
   property node and doesn't have to be on a child.  Do we agree that it
can
   even be on the parent of the property node and still be persistant?
   Should we discourage the client from doing this though?

   <D:set>
    <D:prop xml:lang="NL">
      <D:displaynname>Kikkers in de koek</D:displayname>
    </D:prop>
   </D:set>


   ------------------------------------------
   Phone: 914-784-7569,   ccjason@us.ibm.com

Received on Thursday, 26 April 2001 07:33:57 UTC