W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

RE: Logic for extending text XML elements

From: Lisa Dusseault <lisa@xythos.com>
Date: Wed, 6 Jun 2001 13:12:48 -0700
To: <w3c-dist-auth@w3.org>, "Eric Sedlar" <Eric.Sedlar@oracle.com>
Message-ID: <HPELJFCBPHIPBEJDHKGKOEEKCGAA.lisa@xythos.com>
It makes sense to me that you can't extend simpleType to be complexType.
That answers my concern precisely -- as long as we recommend this
restriction for current and future WebDAV extensions.

(Since WebDAV doesn't explicitly reference Schema inheritance, it seems the
spec is silent on the issue, and I would rather it weren't silent.)

I didn't suggest changing existing datatypes at all.

lisa

> -----Original Message-----
> From: Eric Sedlar [mailto:Eric.Sedlar@oracle.com]
> Sent: Tuesday, June 05, 2001 10:49 AM
> To: Lisa Dusseault; w3c-dist-auth@w3.org
> Subject: RE: Logic for extending text XML elements
>
>
> I'm not exactly sure what you mean by container, but you can't extend
> simpleType XML elements to become complexType ones (which can contain
> subelements) in XML schema via the Schema inheritance mechanism, so
> rather than updating the DTD/Schema, the correct answer to me is to use
> inheritance of XML datatypes to get the restriction you want and NOT
> change existing datatypes.
>
> > -----Original Message-----
> > From: Lisa Dusseault [mailto:lisa@xythos.com]
> > Sent: Tuesday, June 05, 2001 10:50 AM
> > To: Eric Sedlar; w3c-dist-auth@w3.org
> > Subject: RE: Logic for extending text XML elements
> >
> >
> > I see what you mean, however as we extend WebDAV we frequently
> update the
> > XML Schema/DTD.  E.g. we are considering taking propfind and adding an
> > <include> element to a container that coudln't previously hold
> > that element.
> > What's the difference between that and updating the schema for
> an element
> > that contains strings?
> >
> > Adding new elements to containers that already hold XML elements
> > seems like
> > A Good Way to extend DAV.
> > Adding new elements to containers that previously only held text
> > seems like
> > A Bad Way to extend DAV.  If there's consensus on this, perhaps we could
> > state as much.
> >
> > lisa
> >
> > > -----Original Message-----
> > > From: w3c-dist-auth-request@w3.org
> > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar
> > > Sent: Tuesday, June 05, 2001 10:00 AM
> > > To: w3c-dist-auth@w3.org
> > > Subject: RE: Logic for extending text XML elements
> > >
> > >
> > > 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 Wednesday, 6 June 2001 16:14:29 GMT

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