Sorry to take so long answering this -- I've been busy.
First, I agree with you about not allowing the target of an
insert-before or insert-after to be an attribute. This makes a lot of
sense.
Second, I took another look at the XUpdate spec. One of the things I
noticed is that the "instructions" elements (element, attribute, text,
processing-instruction, and comment) are almost identical to the
computed constructors (section 3.7) in XQuery. The major differences
appear to be:
1) Attribute constructors must be the first constructors inside an
element constructor in XQuery, while attribute elements can appear
anywhere in an element element in XUpdate.
2) The constructors in XQuery are obviously more liberal in the number
of things they can accept, such as FLWOR and XPath statements.
That said, it seems reasonable to use the whitespace rules (section
3.7.3) from XQuery in XUpdate, since both are solving the same problem.
These basically state that whether uninterrupted whitespace between
constructors is preserved is controlled by an option in the query
header. (XUpdate could add an attribute to the modifications element.)
Whitespace within constructors is always preserved.
In XUpdate terms, whitespace inside the attribute, text,
processing-instruction, and comment elements is always preserved.
Whitespace in an element constructor is preserved if (a) the option to
preserve whitespace is set to true (preserve, etc.) or (b) the
whitespace is broken by mixed content.
For example, in the following:
<xupdate:append select="/addresses" child="last()">
<xupdate:element name="address">
<town>San Francisco</town>
</xupdate:element>
</xupdate:append>
the whitespace before <town> and after </town> is preserved only if the
option to preserve whitespace is on. But in the following:
<xupdate:append select="/addresses" child="last()">
<xupdate:element name="address">
The population of <town>San Francisco</town> is roughly 1
million.
</xupdate:element>
</xupdate:append>
all whitespace after <xupdate:element name="address"> and before
</xupdate:element> is preserved because it contains non-whitespace
characters. One consequence of this is that whitespace inside the
<xupdate:element> element is also preserved when the only content is
text, as in the following:
<xupdate:append select="/addresses" child="last()">
<xupdate:element name="address">
192 Sylvan Way
</xupdate:element>
</xupdate:append>
The only difficulty here is how to handle attribute children of an
element element. For example, it is not clear what to do with:
<xupdate:append select="/addresses" child="last()">
<xupdate:element name="address">
192 Sylvan Way
<xupdate:attribute name="type">street</xupdate:attribute>
</xupdate:element>
</xupdate:append>
The easiest solution is to simply extract the attribute element, leave
all the remaining whitespace, and then deal with it according to the
above rules.
On an unrelated subject, the spec should state that the DTD cannot
validate all XUpdate documents, since the xupdate:element element
apparently allows element literals (e.g. <town>) and presumably comment
and processing instruction literals (<!-- -->, <? ?>) as well.
-- Ron
Jeroen Breedveld wrote:
>
> || -----Original Message-----
> || From: [EMAIL PROTECTED]
> || [mailto:[EMAIL PROTECTED] On Behalf Of Ronald Bourret
> || Sent: woensdag 26 februari 2003 19:03
> || To: [EMAIL PROTECTED]
> || Subject: Re: Tests and other things
> ||
> || Just to be clear. The following should be legal:
> ||
> || <xupdate:insert-before(after) ...>
> || <xupdate:attribute .../>
> || </xupdate:insert-before(after)>
> ||
> || That is, I should be allowed to use a pretty-printed
> || document when inserting an attribute. It is up to the
> || implementation to ignore the whitespace surrounding the
> || xupdate:attribute element.
>
> Ok, so:
>
> this is legal: <xupdate:insert-before(after) ...><xupdate:attribute
> .../></xupdate:insert-before(after)>
>
> and is considered the same as this:
>
> <xupdate:insert-before(after) ...>
> <xupdate:attribute .../>
> </xupdate:insert-before(after)>
>
> This would be illegal (assuming insert-before(-after) selects an
> attribute)
>
> <xupdate:insert-before(after) ...>
> <xupdate:attribute .../>
> <xupdate:text>bla</xupdate:text> <!-- or any other constructor element
> not the same as xupdate:attribute -->
> </xupdate:insert-before(after)>
>
> || > Also, insert-before(-after) operations selecting elements
> || should in my
> || > opinion not contain <xupdate:attributes> constructor
> || elements because
> || > I see no logic in inserting attribute before (or after)
> || elements. At
> || > the moment Lexus allows you to do it but it appends the
> || attribute to
> || > the parent of the selected element, not very logical.
> ||
> || Agreed? See next comment.
> ||
> || I just re-read the two statements above, and it seems that,
> || in order to insert a new attribute, I have to use an XPath
> || selector that selects an existing attribute. Is this
> || correct? If so, how do I add an attribute to an element
> || that doesn't have any attributes?
>
> To append an attribute to existing element you use:
>
> <xupdate:append select="/some/element">
> <xupdate:attribute name="bla">something</xupdate:attribute>
> </xupdate:append>
>
> Note that the whitespaces before and after <xupdate:attribute/> are
> appended to the /some/element
> You can see this in action here:
> http://support.x-hive.com/xupdate/index.html
> by pasting this xupdate query in the query field:
>
> <?xml version="1.0"?>
> <lexus:modifications version="1.0"
> xmlns:lexus="http://www.xmldb.org/xupdate";>
> <lexus:append select="//[EMAIL PROTECTED]'Lars']/town">
>
> <lexus:attribute name="bla">something</lexus:attribute>
>
> </lexus:append>
> </lexus:modifications>
>
> Writing this I realise that there is another (simple) solution to this
> problem;
>
> insert-before(-after) operations are not allowed to select attributes
> just like append operations are only allowed to select elements. Seems a
> logical thing to do since the XML spec doesn't specify an order in the
> attributes anyway. Any thoughts?
>
> Jeroen
----------------------------------------------------------------------
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe: mailto:[EMAIL PROTECTED]
Contact administrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
----------------------------------------------------------------------
