1st :
Lib-search does NOT have functionality to specify collation on a PER facet 
basis. Only the config (for all facets) is an option. If I wanted this 
functionality, I would need to implement it as a lib-search add-on?

2nd:
when specifically using T0000 collation option as such:
en/S1/AS/T0000

What is the rule regarding witch value is returned for cts:element-values 
function?

a + b
a - b
a     b
a b

I can see that it is rolling them up accurately(4), but why a + b?


--- On Wed, 12/17/08, [email protected] 
<[email protected]> wrote:
From: [email protected] 
<[email protected]>
Subject: General Digest, Vol 54, Issue 24
To: [email protected]
Date: Wednesday, December 17, 2008, 2:29 PM

Send General mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://xqzone.com/mailman/listinfo/general
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of General digest..."


Today's Topics:

   1. absolute path: xdmp:document-get vs       xdmp:uri-is-file
      (Eric Palmitesta)
   2. Re: absolute path: xdmp:document-get      vs      xdmp:uri-is-file
      (Eric Palmitesta)
   3. RE: absolute path:        xdmp:document-getvs     xdmp:uri-is-file
      (Danny Sokolsky)
   4. Collation Lexicon Frequency (Paul M)
   5. Re: absolute      path:   xdmp:document-getvs     xdmp:uri-is-file
      (Eric Palmitesta)
   6. RE: Collation Lexicon Frequency (Danny Sokolsky)
   7. Re: A couple of questions about the       Alerting capabilities in
      ML 4.0 (Wayne Feick)


----------------------------------------------------------------------

Message: 1
Date: Wed, 17 Dec 2008 15:40:42 -0500
From: Eric Palmitesta <[email protected]>
Subject: [MarkLogic Dev General] absolute path: xdmp:document-get vs
        xdmp:uri-is-file
To: ML Developer Mailing List <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi all,

Hopefully I'm missing something and someone can put me on the right track.

It's fine to say "if (exists(doc('blah'))) then" because
doc will simply 
return () rather than producing an error.  How do I do the same with 
xdmp:document-get?  Since xdmp:document-get errors with "file not
found" 
(if a file is indeed not found), I was hoping to check if the call will 
fail before I make it.  The xdmp:uri-is-file function looks like the 
wrong one to use, though, because an absolute path means something 
different:

The api for xdmp:document-get says
"On the filesystem, the path can be fully qualifed or relative. Relative 
pathnames are resolved from the directory in which MarkLogic Server is 
installed."

The api for xdmp:uri-is-file says
says "If the URI begins with a '/', it is relative to the root
directory 
of the application server."

Is a try/catch the only way?

Thanks,

Eric


------------------------------

Message: 2
Date: Wed, 17 Dec 2008 15:44:23 -0500
From: Eric Palmitesta <[email protected]>
Subject: Re: [MarkLogic Dev General] absolute path: xdmp:document-get
        vs      xdmp:uri-is-file
To: General Mark Logic Developer Discussion
        <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Shorter version of my question: is there a file-system equivalent of the 
fn:doc-available function?

Eric

Eric Palmitesta wrote:
> Hi all,
> 
> Hopefully I'm missing something and someone can put me on the right
track.
> 
> It's fine to say "if (exists(doc('blah'))) then"
because doc will simply 
> return () rather than producing an error.  How do I do the same with 
> xdmp:document-get?  Since xdmp:document-get errors with "file not
found" 
> (if a file is indeed not found), I was hoping to check if the call will 
> fail before I make it.  The xdmp:uri-is-file function looks like the 
> wrong one to use, though, because an absolute path means something 
> different:
> 
> The api for xdmp:document-get says
> "On the filesystem, the path can be fully qualifed or relative.
Relative 
> pathnames are resolved from the directory in which MarkLogic Server is 
> installed."
> 
> The api for xdmp:uri-is-file says
> says "If the URI begins with a '/', it is relative to the
root directory 
> of the application server."
> 
> Is a try/catch the only way?
> 
> Thanks,
> 
> Eric
> _______________________________________________
> General mailing list
> [email protected]
> http://xqzone.com/mailman/listinfo/general


------------------------------

Message: 3
Date: Wed, 17 Dec 2008 12:57:50 -0800
From: "Danny Sokolsky" <[email protected]>
Subject: RE: [MarkLogic Dev General] absolute path:
        xdmp:document-getvs     xdmp:uri-is-file
To: "General Mark Logic Developer Discussion"
        <[email protected]>
Message-ID:
        <[email protected]>
Content-Type: text/plain;       charset="us-ascii"

I don't know of another way besides try/catch (which is great for this
type of thing).  

-Danny

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Eric
Palmitesta
Sent: Wednesday, December 17, 2008 12:44 PM
To: General Mark Logic Developer Discussion
Subject: Re: [MarkLogic Dev General] absolute path: xdmp:document-getvs
xdmp:uri-is-file

Shorter version of my question: is there a file-system equivalent of the

fn:doc-available function?

Eric

Eric Palmitesta wrote:
> Hi all,
> 
> Hopefully I'm missing something and someone can put me on the right
track.
> 
> It's fine to say "if (exists(doc('blah'))) then"
because doc will
simply 
> return () rather than producing an error.  How do I do the same with 
> xdmp:document-get?  Since xdmp:document-get errors with "file not
found" 
> (if a file is indeed not found), I was hoping to check if the call
will 
> fail before I make it.  The xdmp:uri-is-file function looks like the 
> wrong one to use, though, because an absolute path means something 
> different:
> 
> The api for xdmp:document-get says
> "On the filesystem, the path can be fully qualifed or relative.
Relative 
> pathnames are resolved from the directory in which MarkLogic Server is

> installed."
> 
> The api for xdmp:uri-is-file says
> says "If the URI begins with a '/', it is relative to the
root
directory 
> of the application server."
> 
> Is a try/catch the only way?
> 
> Thanks,
> 
> Eric
> _______________________________________________
> General mailing list
> [email protected]
> http://xqzone.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general


------------------------------

Message: 4
Date: Wed, 17 Dec 2008 13:58:20 -0800 (PST)
From: Paul M <[email protected]>
Subject: [MarkLogic Dev General] Collation Lexicon Frequency
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

Hi:

I have the following docs:

doc1
<elem1>dear sir</elem1>
doc2
<elem1>dear     sir</elem1>
doc3
<elem1>dear   sir       </elem1>

All have a variable amount of white space characters. Using lib-search,
specifically these functions:
cts:element-values($element-qname, "", $options, $base-query) (:above
three docs returned:)
cts:frequency($value) (:elem1 has three facets associate with $base-query, each
with a value of 1:)

Each doc contains elem1, each with a unique value. There does not exist a
simply method for the frequency function to consider the above three elements as
"the same". (They likely hash to different values?)

The only easy method is to normalize the data by stripping white-space from the
documents themselves?



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://xqzone.marklogic.com/pipermail/general/attachments/20081217/e8a160a0/attachment-0001.html

------------------------------

Message: 5
Date: Wed, 17 Dec 2008 17:19:07 -0500
From: Eric Palmitesta <[email protected]>
Subject: Re: [MarkLogic Dev General] absolute   path:
        xdmp:document-getvs     xdmp:uri-is-file
To: General Mark Logic Developer Discussion
        <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Is there any way for an (.xqy) file to refer relatively to an (.xml) 
file on the filesystem?  Note that (.xqy) files need not be in a 
subdirectory of the Marklogic installation.

My motivation here is a localization file (en.xml, fr.xml, etc) 
containing keys and strings for i18n purposes.  This file can easily be 
inserted into the database, but editing then becomes tedious.

Eric

Danny Sokolsky wrote:
> I don't know of another way besides try/catch (which is great for this
> type of thing).  
> 
> -Danny
> 
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Eric
> Palmitesta
> Sent: Wednesday, December 17, 2008 12:44 PM
> To: General Mark Logic Developer Discussion
> Subject: Re: [MarkLogic Dev General] absolute path: xdmp:document-getvs
> xdmp:uri-is-file
> 
> Shorter version of my question: is there a file-system equivalent of the
> 
> fn:doc-available function?
> 
> Eric
> 
> Eric Palmitesta wrote:
>> Hi all,
>>
>> Hopefully I'm missing something and someone can put me on the
right
> track.
>> It's fine to say "if (exists(doc('blah'))) then"
because doc will
> simply 
>> return () rather than producing an error.  How do I do the same with 
>> xdmp:document-get?  Since xdmp:document-get errors with "file not
> found" 
>> (if a file is indeed not found), I was hoping to check if the call
> will 
>> fail before I make it.  The xdmp:uri-is-file function looks like the 
>> wrong one to use, though, because an absolute path means something 
>> different:
>>
>> The api for xdmp:document-get says
>> "On the filesystem, the path can be fully qualifed or relative.
> Relative 
>> pathnames are resolved from the directory in which MarkLogic Server is
> 
>> installed."
>>
>> The api for xdmp:uri-is-file says
>> says "If the URI begins with a '/', it is relative to the
root
> directory 
>> of the application server."
>>
>> Is a try/catch the only way?
>>
>> Thanks,
>>
>> Eric
>> _______________________________________________
>> 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


------------------------------

Message: 6
Date: Wed, 17 Dec 2008 14:39:53 -0800
From: "Danny Sokolsky" <[email protected]>
Subject: RE: [MarkLogic Dev General] Collation Lexicon Frequency
To: <[email protected]>, "General Mark Logic Developer
Discussion"
        <[email protected]>
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="us-ascii"

One approach is to use a space-insensitive collation for the range
index.  Then these would appear the same.  Here is a simple example:

 

xquery version "1.0-ml";

declare default collation "http://marklogic.com/collation/en/S1/AS";;

 

"hello there" = "hello    there"

(: returns true :)

 

-Danny

 

From: [email protected]
[mailto:[email protected]] On Behalf Of Paul M
Sent: Wednesday, December 17, 2008 1:58 PM
To: [email protected]
Subject: [MarkLogic Dev General] Collation Lexicon Frequency

 

Hi:

I have the following docs:

doc1
<elem1>dear sir</elem1>
doc2
<elem1>dear     sir</elem1>
doc3
<elem1>dear   sir       </elem1>

All have a variable amount of white space characters. Using lib-search,
specifically these functions:
cts:element-values($element-qname, "", $options, $base-query) (:above
three docs returned:)
cts:frequency($value) (:elem1 has three facets associate with
$base-query, each with a value of 1:)

Each doc contains elem1, each with a unique value. There does not exist
a simply method for the frequency function to consider the above three
elements as "the same". (They likely hash to different values?)

The only easy method is to normalize the data by stripping white-space
from the documents themselves?

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://xqzone.marklogic.com/pipermail/general/attachments/20081217/5c4f5544/attachment-0001.html

------------------------------

Message: 7
Date: Wed, 17 Dec 2008 22:44:05 +0000
From: Wayne Feick <[email protected]>
Subject: Re: [MarkLogic Dev General] A couple of questions about the
        Alerting capabilities in ML 4.0
To: General Mark Logic Developer Discussion
        <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"

Hi Darin,

You are correct, that the alerting pipeline alerts on entire documents.
Adding some sort of xpath support to match the first argument of
cts:search() is something we can ponder for a future release.

Thanks for the feedback.

Wayne.


On Tue, 2008-12-16 at 18:10 -0800, Darin McBeath wrote:
> Thanks for the clarification Wayne.  One last question.
>  
> I'm not sure the fragmentation is that much of a 'special'
case.
> Couldn't one encounter an issue whenever the first paramter to
> cts:search (used to scope the search) was something other than the
> root of the document?  I guess what I'm trying to get clarification on
> is the following:
>  
> The built-in 'alerting' pipeline will work if the root of the
document
> is the fragmentation level and is also the scope of the search.
> Otherwise, one will want to construct their own home-grown alerting
> pipeline and appropriately handle the spawn-matching-actions.  I think
> this is pretty much what I'm concluding but wanted to first get
> confirmation.  If this is true, this is something that you might want
> to consider adding to the alerting section in ch 25 of the developer
> documentation.
>  
> Thanks again for your patience and help.
>  
> Darin.



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://xqzone.marklogic.com/pipermail/general/attachments/20081217/fad9609b/attachment.html

------------------------------

_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general


End of General Digest, Vol 54, Issue 24
***************************************



      
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general

Reply via email to