RE: Tests and other things
|| -Original Message- || From: [EMAIL PROTECTED] || [mailto:[EMAIL PROTECTED] On Behalf Of Vladimir || R. Bossicard || Sent: dinsdag 25 februari 2003 13:55 || To: [EMAIL PROTECTED] || Subject: Re: Tests and other things || || || This bug hasn't been solved yet because I think we should first || discuss some kind of fundamental solution to handling || white-spaces. || || What do you propose? Let's discuss this using some use-cases: xupdate:modifications version=1.0 xmlns:xupdate=http://www.xmldb.org/xupdate; xupdate:insert-before select=/addresses/[EMAIL PROTECTED]'Andreas']/@name xupdate:attribute name=id2/xupdate:attribute /xupdate:insert-before /xupdate:modifications Clearly, in this case your not interested in the white-spaces outside the xupdate:attribute elements (in fact it causes problems in Lexus right now). 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? 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=townRotterdam/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 ? xupdate:modifications version=1.0 xmlns:xupdate=http://www.xmldb.org/xupdate; xupdate:insert-before select=/addresses/[EMAIL PROTECTED]'Andreas'] address name=Jeroen townRotterdam/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. Any other solutions or interesting use-case? regards, Jeroen -- X-Hive Corporation e-mail: [EMAIL PROTECTED] phone: +31 10 2818080 http://www.x-hive.com -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Tests and other things
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=townRotterdam/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 townRotterdam/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/ --
Re: Tests and other things
Are you asking me a fundamental question the existence of an insert-before and insert-after method in the WD or are you wondering why insert-before and insert-after are tested when there is no order in the attributes defined? if insert before fails and insert after succeeds and the order is not important, why are both methods not using the same code? (the code of insert after). -Vladimir -- Vladimir R. Bossicard Apache Xindice - http://xml.apache.org/xindice -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Tests and other things
Jeroen, thanks for your answer. Very helpful. XhiveNodeMatcher doesn't verify the order of the attributes because the XML spec. doesn't specify that attributes are ordered. so why the insert before and insert after methods if only a insert method is needed? (I'm sure I'm missing the point, but I ask nevertheless :-) ) It seems to me that we need some fundamental discussion on the maillinglist and fill the holes in the WD to make it a complete. So since these two bugs are well known, I'll try to upgrade to the latest Xalan, ignoring these bugs. I'm maintaining junit-addons on sf (collection of classes for JUnit) and if you want to donate the NodeMatcher class, let me know :-) I'm sure this class will be very helpful to other users. -Vladimir -- Vladimir R. Bossicard Apache Xindice - http://xml.apache.org/xindice -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
