Hello All,
Now i have successfully connected my xquery with java using
MLJAM, but i have problem while generating output,
Actually my task is to convert one XML format to another XML format, I read
the XML file in my WEBDAV drive, after
transformation writing it into my local driv
Just a quick notification of public deliveries of XML-related
training by Crane Softwrights Ltd. as we travel in Europe, North
America and the world in 2010:
2010-03-04 - Free Internet Lectures using Skype and Yugma
17:00UTC Introduction to the Universal Business Language
==> " 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 X
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: general-boun...@developer.m
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 th
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-
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
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 wrot
Hi Mano,
Today's questions first:
Re: snippets, take a look at the API documentation for search:snippet().
You can use search:get-default-options() to see the node
that is used by default. You can use to control: snippet
length; the amount of padding around each highlighed term; the maximum
Hi Colleen,
I just upgraded to 4-1.5 and get the same error.
Bob
Bob, I think you're running into a bug that was fixed in 4.1-5; if you
upgrade and still see this behavior, please let us know immediately.
___
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 attr
Hi,
Why "search:search()" query doesnt give result of all the matches in
?
Why "search:search()" skip some of the matches in the ?
Whether "search:search()" result depends upon source file size or based on
license?
Regards,
Mano
From: mano m
To: gen
12 matches
Mail list logo