W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

RE: RFC2518 ambiguity on creationdate/lastmodifieddate

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 8 Feb 2002 09:34:56 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B105CE0559@SUS-MA1IT01>
To: w3c-dist-auth@w3.org
My rationale for rejecting (c) was:
"(c) violates the requirement in 8.1 that missing
 property errors be reported"

So that leaves (a) as my choice for the most consistent
interpretation of 2518.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Friday, February 08, 2002 8:42 AM
To: Clemm, Geoff; w3c-dist-auth@w3.org
Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate


OK,

so what's your suggestion then? a) or c)?



> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, February 08, 2002 2:34 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate
> 
> 
> Yes, I'd agree that this clearly supports Julian's position
> that an empty element of the form "<a></a>" matches a #PCDATA
> DTD declaration.
> 
> So I modify my rejection of choice <b> (i.e. returning an empty
> element) to be: The definition of DAV:creationdate states:
> "If present, it contains a timestamp of the moment when the
> resource was created".  An empty value does not meet this
> requirement (although one could debate the meaning of "present").
> 
> Cheers,
> Geoff
> 
> 
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Friday, February 08, 2002 3:38 AM
> To: Clemm, Geoff; w3c-dist-auth@w3.org
> Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate
> 
> 
> Geoff,
> 
> as far as I can tell, PCDATA is defined in:
> 
> http://www.w3.org/TR/2000/REC-xml-20001006#NT-Mixed
> 
> where it says:
> 
> [Definition: An element type has mixed content when elements of that type
> may contain character data, optionally interspersed with child 
> elements.] In
> this case, the types of the child elements may be constrained, 
> but not their
> order or their number of occurrences:
> 
> Note the "may".
> 
> Besides, this would mean that with DTDs you can't have elements that are
> restricted to arbitrary text content, but may not be empty. This 
> is clearly
> not the case.
> 
> Finally: in doubt, try it with a validating parser.
> 
> 
> 
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> > Sent: Thursday, February 07, 2002 9:33 PM
> > To: w3c-dist-auth@w3.org
> > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate
> >
> >
> > Well, there always is that question about whether <foo></foo>
> > is a node with no children, or a node with a single empty
> > string child.  Since section 2.4 of the xml spec says:
> > "All text that is not markup constitutes the character data of the
> > document",
> > and since I do not consider "nothing" to be "text", I go with the
> > interpretation that says <foo></foo> contains no character data,
> > and therefore does not match a #PCDATA declaration.
> >
> > Cheers,
> > Geoff
> >
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de]
> > Sent: Thursday, February 07, 2002 1:01 PM
> > To: Clemm, Geoff; w3c-dist-auth@w3.org
> > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate
> >
> >
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> > > Sent: Thursday, February 07, 2002 6:55 PM
> > > To: w3c-dist-auth@w3.org
> > > Subject: RE: RFC2518 ambiguity on creationdate/lastmodifieddate
> > >
> > >
> > > 2518 is at best ambiguous, and a worst, contradictory on this topic.
> > >
> > > I would vote for (a) property not found.
> > >
> > > (b) is a possible interpretation, but an empty value
> > > violates the DTD for this property.
> >
> > Why would that be a violation?
> >
> 
Received on Friday, 8 February 2002 09:35:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:59 GMT