- From: Eric Sedlar <Eric.Sedlar@oracle.com>
- Date: Tue, 5 Jun 2001 09:59:31 -0700
- To: <w3c-dist-auth@w3.org>
The XML schema for <d:href> should be defined as a simple type (like "anyURI", which subclasses "string"), which disallows element children. I assume the DTD says the same thing (I'm not as familiar with DTD). > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, June 05, 2001 9:29 AM > To: w3c-dist-auth@w3.org > Subject: Logic for extending text XML elements > > > I've run into a minor issue relating to XML syntax and WebDAV > extensibility. > > I'm parsing: > <D:href>http://myserver.com/</D:href> > > Since an XML element can legally contain both text and elements (e.g. > <P>Hello <em>sailor!</em></P>), it's conceivable that in the future the > <href> element could be extended to have: > > <D:href>http://myserver.com/ > <expires>123486</expires> > more-stuff > </D:href> > > RFC 2518 says: > "All DAV compliant resources MUST ignore any unknown XML element and > all its children encountered while processing a DAV method that uses > XML as its command language." > > That would indicate that I should ignore the <expires> element. I can do > that. But what does "ignore" mean? > - Do I treat it as a separator so that "http://myserver.com/" is one text > child of DAV:href and "more-stuff" is another text child? How do I know > which one to treat as the URL, particularly if they both look like urls? > - Do I conceptually remove the ignored element? That would leave > <DAV:href> with a single text child containing white space, approximately: > "http://myserver.com/ more-stuff". > > Since all this is rather ugly, I'd most like to have a sentence > added to RFC > 2518 (section 14?) that states at a minimum that "text elements should NOT > have their syntax extended by adding XML elements because this is unlikely > to be backward-compatible." I think we already instinctively follow this > guideline, but it's hard to write solid code based on guesses and > predictions that aren't written down. > > Any other proposals or insights? > > lisa > >
Received on Tuesday, 5 June 2001 13:07:35 UTC