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