==> " XML does not have a specified way of serializing an attribute node
by itself"
Correct, but the XCC API is not a text serialization API. Its a
in-memory API layer were XDM types do have meaning, even if they do not
have a standardized text serialization.
Since XQuery can produce any XDM type, XCC should present those types to
the program at the API layer.
One very good use case for example.
Suppose I wanted to run one XQuery script in ML to produce values to be
passed as variables to another XQuery script (or a local Xquery or XSLT
processes).
Since XQuery can produce any XDM value then this should work.
Simply because some XQuery implementations have this problem doesn't
make it right.
Some (I would say 'good' ) XQuery implementations (such as Saxon ) allow
full XDM values as per xquery specs as results even if they can't be
serialized in a standardized form.
Now if you want discuss serialization instead of the API layer ...
Another use case ...
Although it may be theoretically 'odd' to try to serialize a plain
attribute ... I have found it an extremely common practice for new users
of XQuery to not realize this and run queries such as
/foo/@bar
and *expect* the result to be printed as text. Certainly there is no
'standardized' way to do this so instead users get some really ugly low
level error that doesnt help them at all. Then they blame the program
when in fact since there is no standardized way of displaying the
results, its not wrong to do what they really want. It would be really
good, IMHO. I would like to provide them what they expect, which is
really /foo/@bar/string() ... Is that so bad ? To give a large
category of users what they actually want even if us XML geeks know its
'not standardized' ? It doesnt break any standards and it makes entry
into XQuery a lot easier for people.
I can't do that using XCC today because XCC is not supplying the type
information correctly.
It is clearly XCC which is broken.
-David
See the discussion related to this issue at :
http://xml.calldei.com/XDMSerialize
From: [email protected]
[mailto:[email protected]] On Behalf Of Danny
Sokolsky
Sent: Monday, March 01, 2010 4:45 PM
To: General Mark Logic Developer Discussion
Subject: RE: [MarkLogic Dev General] Bug in XCC - lone attributes
reportingas elements.
Hi David,
Keep in mind that XML does not have a specified way of serializing an
attribute node by itself, so any serialization of a plain attribute node
is a little odd. For example, I don't think any XML parser can
deserialize a plain attribute node.
-Danny
From: [email protected]
[mailto:[email protected]] On Behalf Of Lee, David
Sent: Monday, March 01, 2010 12:09 PM
To: General Mark Logic Developer Discussion
Subject: RE: [MarkLogic Dev General] Bug in XCC - lone attributes
reporting as elements.
Thanks, this seems a problem in the XCC binary serialization. This
really needs improvement if XCC cant serialize arbitrary XDM values.
Unfortunately I can't use your suggestion as my use case is to run
other-peoples-code ... so I cant require them to add extra stuff to it.
Well ... except that I'm telling them to run fn:string() on attributes,
but I'd like to handle *any XDM Type* returned from an XQuery.
FYI my use case is the marklogic extension to xmlsh
http://www.xmlsh.org/MarkLogic
In particular the query command where I dont have any ability to enforce
special xquery code.
Thanks for your reply.
As a side note I'm slowly working on a proposal for XDM serialization
which overlaps some of this issue... its a general case that many xquery
processors dont actually handle XDM output like they should.
http://xml.calldei.com/XDMSerialize
-David
----------------------------------------
David A. Lee
Senior Principal Software Engineer
Epocrates, Inc.
[email protected] <mailto:[email protected]>
812-482-5224
From: [email protected]
[mailto:[email protected]] On Behalf Of Sam Neth
Sent: Monday, March 01, 2010 2:59 PM
To: General Mark Logic Developer Discussion
Subject: Re: [MarkLogic Dev General] Bug in XCC - lone
attributesreportingas elements.
Unfortunately the result sequence sent by the server simply doesn't
contain this information; you might consider obtaining the type
yourself, using the xdmp:node-kind builtin, and including that
information in the result, possibly by wrapping a special element around
attribute nodes:
xdmp:node-kind($x) = "attribute") then <attribute-node>{ $x
}</attribute-node> else $x
This also has the benefit of making the attribute name available on the
client.
On Mar 1, 2010, at 11:19 AM, Lee, David wrote:
Thanks !
In my use case, any kind of method to accurately determine the Xdm type
of results would be good enough, even if full attribute (XdmAttribute)
support wasnt implemented. I I could only 'know' an item was an
attribute then I can serialize it with the current implementation (I've
tested
ResultItem.writeTo( outputStream ) and it writes the
value of the attribute just fine).
So just knowing the XDM type would be sufficient for me.
Thanks for noting this issue.
-David Lee
From: [email protected]
[mailto:[email protected]] On Behalf Of Sam Neth
Sent: Monday, March 01, 2010 1:51 PM
To: General Mark Logic Developer Discussion
Subject: Re: [MarkLogic Dev General] Bug in XCC - lone attributes
reportingas elements.
This would be the appropriate place to report a bug or RFE, assuming no
support contract is in place. In this case, the behavior you describe
is a known limitation of XCC which we are already tracking as an RFE.
You may consider your interest noted.
On Mar 1, 2010, at 5:46 AM, Lee, David wrote:
Whats the best way to report this bug ?
If I run an ad-hoc query in XCC which returns a single attribute, for
example :
attribute {"foo"} {"bar"}
The resulting item in XCC is reporting itself as an element, but (of
course) wont serialize.
I would like to be able to detect lone attributes for special handling
but I cant because XCC is incorrectly representing them as Elements
Example code fragment:
while (rs.hasNext()) {
ResultItem rsItem = rs.next();
ItemType type = rsItem.getItemType();
XdmItem item = rsItem.getItem();
if( (type.isNode() && item instanceof XdmAttribute) )
// FAILS TEST ... item is an
ElementImpl not an XdmAttribute
---
item ElementImpl (id=62)
stream null
stringVal "bar" (id=73)
type NodeType (id=58)
----------------------------------------
David A. Lee
Senior Principal Software Engineer
Epocrates, Inc.
[email protected]
812-482-5224
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
