RE: Logic for extending text XML elements

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Tuesday, June 05, 2001 6:29 PM
> 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".

I think this makes the most sense. You could also define it as

- remove unknown child elements,
- use DOM's normalize() method (or equivalent in your API)
- use the value of the resulting text node

> 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.

I agree it's ugly, but maybe it needs to be done nevertheless. How about
just describing the "correct" way to get the text value?

Received on Tuesday, 5 June 2001 14:13:05 UTC