Jeroen Breedveld wrote: > Solutions would be: > > 1. Let Lexus ignore / stop on illegal combinations > Doesn't sound very attractive to me: How many of these combinations do > there exist? Do we have keep on patching Lexus' code when new illegal > combinations are discovered?
What's the illegal combination here? The whitespace? Or the insert-before with an attribute? In either case, it seems that the XUpdate spec should clearly enumerate each of these (so the user can create valid input) and Lexus should stop on them. Yes, it might be a lot of work to do this, but it's the only way to guarantee interoperability of XUpdate implementations. > 2. Let Lexus ignore whitespaces > May be difficult to implement (I'm not very familiar with SAX), > whitespaces in text nodes cannot be ignored ofcourse but can whitespaces > before and after text-nodes be ignored? > > <xupdate:modifications version="1.0" > xmlns:xupdate="http://www.xmldb.org/xupdate";> > <xupdate:insert-before select="/addresses/[EMAIL PROTECTED]'Andreas']"> > <xupdate:element name="address"> > <xupdate:attribute name="name"> Jeroen </xupdate:attribute> > <xupdate:element name="town">Rotterdam</xupdate:element> > </xupdate:element> > </xupdate:insert-before> > </xupdate:modifications> > > In this case it seems to me that the whitespace between the elements > could be ignored but can the whitespaces before the new attribute value > " Jeroen "? No. The attribute value is " Jeroen ", not "Jeroen". > <xupdate:modifications version="1.0" > xmlns:xupdate="http://www.xmldb.org/xupdate";> > <xupdate:insert-before select="/addresses/[EMAIL PROTECTED]'Andreas']"> > <address name="Jeroen"> > <town>Rotterdam</town> > </address> > </xupdate:insert-before> > </xupdate:modifications> > > In this case the whitespaces between elements cannot be all ignored > because it may be the intention of the user to have whitespaces after > the <address name="Jeroen"> and </town> elements. It might also be the intention of the user to have whitespaces before <address> and after </address>. I'm not very familiar with XUpdate, but based on the examples above, I can see the following rules: 1) The entire content of an xupdate:element or xupdate:attribute element is the new content of that element or attribute. This includes all whitespace. 2) The entire content of an xupdate:insert-before or xupdate:insert-after element is the new content of that element. This includes all whitespace. Notes: 1) If an updated/inserted element has element content, including all whitespace does no harm. That is, such whitespace will be ignored by the application that eventually processes the XML document anyway. 2) If an updated/inserted element has mixed or PCDATA-only content, including all whitespace is the only safe thing to do. This is because there is no way to tell what the user's intention was. (If you wanted, you could add an attribute to element/attribute/insert-before/insert-after to strip leading and trailing whitespace, but this seems unnecessary. If somebody doesn't want such whitespace, it is easy enough for them to simply not include it.) 3) For attributes, including all whitespace is also the only safe thing to do. Note that a system that new the schema of the updated document could be more intelligent here. For example, it could look at the content model of an updated or inserted element and determine whether it could ignore whitespace. However, that seems needlessly complex. -- Ron ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
