bug in constraint on constructed nodes

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bug in constraint on constructed nodes

Jean-Marc Vanel-3
Hi all

Starting from an August discussion with Adam and others, I distilled
this standalone XQuery :

let $doc := <county name="Devon" />
return (
    "$doc / @name: "   , $doc / @name ,
    "$doc [ @name ]: " , $doc [ @name ]
)

In short :
$doc / @name         ==> works
$doc [ @name ]       ==> returns nothing

I'm aware that  querying  constructed nodes is not efficient.
Did we know that it is also not accurate ?

--
Jean-Marc Vanel
Conseil et Services / développement & intégration logiciels
Logiciel libre, Web, Java, XML ...
A la pointe de la technique, au service des projets
http://jmvanel.free.fr/ ===) CV, software resources

Mes journaux:
- sujets généraux en Français: http://jmvanel.free.fr/Block-note.html
- sujets informatiques en Français: http://jmvanel.free.fr/notes-informatiques.html
- computer science diary : http://jmvanel.free.fr/computer-notes.html

Worldwide Botanical Knowledge Base
http://wwbota.free.fr/ 
test XML query engine: http://jmvanel.free.fr/protea.html




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug in constraint on constructed nodes

wolfgangmm
Hi Jean-Marc,

> Starting from an August discussion with Adam and others, I distilled
> this standalone XQuery :
>
> let $doc := <county name="Devon" />
> return (
>     "$doc / @name: "   , $doc / @name ,
>     "$doc [ @name ]: " , $doc [ @name ]
> )
>
> In short :
> $doc / @name         ==> works
> $doc [ @name ]       ==> returns nothing

Thanks, I fixed this in CVS. $doc/@name correctly transformed the
constructed fragment into a temporary persistent document before
applying path expression, $doc [ @name ] did not.

Wolfgang


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug in constraint on constructed nodes

Pierrick Brihaye
Hi,

Wolfgang Meier a écrit :

>>let $doc := <county name="Devon" />
>>return (
>>    "$doc / @name: "   , $doc / @name ,
>>    "$doc [ @name ]: " , $doc [ @name ]
>>)
>>
>>In short :
>>$doc / @name         ==> works
>>$doc [ @name ]       ==> returns nothing
>  
> Thanks, I fixed this in CVS. $doc/@name correctly transformed the
> constructed fragment into a temporary persistent document before
> applying path expression, $doc [ @name ] did not.

However, this XQuery is invalid because it returns a parentless
attribute node.

eXist returns :

$doc / @name:
Devon
$doc [ @name ]:
<county name="Devon"/>

whereas the latest Saxon returns :
SENR0001: Cannot serialize a free-standing attribute node (name)

Cheers,

p.b.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug in constraint on constructed nodes

Jean-Marc Vanel-3
Pierrick Brihaye wrote:

> Hi,
>
> Wolfgang Meier a écrit :
>
>>> let $doc := <county name="Devon" />
>>> return (
>>>    "$doc / @name: "   , $doc / @name ,
>>>    "$doc [ @name ]: " , $doc [ @name ]
>>> )
>>>
>>> In short :
>>> $doc / @name         ==> works
>>> $doc [ @name ]       ==> returns nothing
>>
>>  
>> Thanks, I fixed this in CVS. $doc/@name correctly transformed the
>> constructed fragment into a temporary persistent document before
>> applying path expression, $doc [ @name ] did not.
>
>
> However, this XQuery is invalid because it returns a parentless
> attribute node.
>
> eXist returns :
>
> $doc / @name:
> Devon
> $doc [ @name ]:
> <county name="Devon"/>
>
> whereas the latest Saxon returns :
> SENR0001: Cannot serialize a free-standing attribute node (name)

Bonsoir Périg .

I trust Saxon as much as you . Obsviously eXist here is tolerant and
likely applies a probably illegal but convenient conversion to string
before outputting .

I'm in favour of non-tolerance , but not everybody might agree ...

--
Jean-Marc Vanel
Conseil et Services / développement & intégration logiciels
Logiciel libre, Web, Java, XML ...
A la pointe de la technique, au service des projets
http://jmvanel.free.fr/ ===) CV, software resources

Mes journaux:
- sujets généraux en Français: http://jmvanel.free.fr/Block-note.html
- sujets informatiques en Français: http://jmvanel.free.fr/notes-informatiques.html
- computer science diary : http://jmvanel.free.fr/computer-notes.html

Worldwide Botanical Knowledge Base
http://wwbota.free.fr/ 
test XML query engine: http://jmvanel.free.fr/protea.html




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug in constraint on constructed nodes

Pierrick Brihaye
Hi,

Jean-Marc Vanel a écrit :

> I trust Saxon as much as you .

Well... I rather trust the specs :-)

> Obsviously eXist here is tolerant and
> likely applies a probably illegal but convenient conversion to string
> before outputting .

string($doc/@name) also makes it :-)

> I'm in favour of non-tolerance , but not everybody might agree ...

IMHO, compliance with the specs is a must.

Cheers,

p.b.



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: bug in constraint on constructed nodes

Adam Retter-7
In reply to this post by Jean-Marc Vanel-3

I would agree, if you are following specifications then they should be
followed strictly.

However I dont see why eXist shouldnt offer its own 'extensions' to these
specifications, but these must be clearly detailed and understood to be
extensions.

Cheers Adam.

-----Original Message-----
From: Pierrick Brihaye [mailto:[hidden email]]
Sent: Thu 9/8/2005 7:06 PM
To: Jean-Marc Vanel
Cc: [hidden email]
Subject: Re: [Exist-open] bug in constraint on constructed nodes
 
Hi,

Jean-Marc Vanel a écrit :

> I trust Saxon as much as you .

Well... I rather trust the specs :-)

> Obsviously eXist here is tolerant and
> likely applies a probably illegal but convenient conversion to string
> before outputting .

string($doc/@name) also makes it :-)

> I'm in favour of non-tolerance , but not everybody might agree ...

IMHO, compliance with the specs is a must.

Cheers,

p.b.



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug in constraint on constructed nodes

Pierrick Brihaye-2
Hi,

Adam Retter wrote:

> I would agree, if you are following specifications then they should be
> followed strictly.
>
> However I dont see why eXist shouldnt offer its own 'extensions' to these
> specifications, but these must be clearly detailed and understood to be
> extensions.

What's the point here ? What extensions to XQuery specs can be imagined
? Personally, I can't see.

However, eXist already does have "extensions" that are definitely not
compliant with the specs : its "fulltext operators". AFAIAC, I would
tend to replace them by dedicated functions even though operators are
more elegant.

Of course, the specs may also be discussed. I also would like to change
a few lines :-)

Cheers,

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:[hidden email]
+33 (0)2 99 29 67 78


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug in constraint on constructed nodes

Jean-Marc Vanel-3
Pierrick Brihaye wrote:

> Hi,
>
> Adam Retter wrote:
>
>> I would agree, if you are following specifications then they should be
>> followed strictly.
>>
>> However I dont see why eXist shouldnt offer its own 'extensions' to
>> these
>> specifications, but these must be clearly detailed and understood to be
>> extensions.
>
>
> What's the point here ? What extensions to XQuery specs can be
> imagined ? Personally, I can't see.

The "tolerant to undeclared conversions" mode could be a non-default mode.
I fear that if eXist suddenly becomes stringent some people's
application might break.
So this "tolerant to undeclared conversions" mode could be a migration path.

> However, eXist already does have "extensions" that are definitely not
> compliant with the specs : its "fulltext operators".

I never liked this syntax. But now there an official W3C alternative:

http://www.w3.org/TR/2005/WD-xquery-full-text-20050404/

Here is an example; the new ftcontains operator means "fulltext contains" :

for $b in /books/book
   where $b/title ftcontains ("dog" with stemming) && "cat"
   return $b/author


It would probably not be difficult to  introduce the new ftcontains
operator :

for $b in /books/book
   where $b/title ftcontains "dog"

in its simplest form , to replace  &= .

But stemming is not implemented, and the syntax for multiple words is
different :
my_node &= "King Queen"

versus :
my_node  ftcontains "King" && "Queen"

Anyway it's just a Working Draft . And dedicated functions are easer to
implment in eXist (maybe because I did several functions and never an
operator ).

> AFAIAC, I would tend to replace them by dedicated functions even
> though operators are more elegant.
>
> Of course, the specs may also be discussed. I also would like to
> change a few lines :-)
>
> Cheers,
>


--
Jean-Marc Vanel 01 39 43 31 46
Conseil et Services / développement & intégration logiciels
Logiciel libre, Web, Java, XML ...
A la pointe de la technique, au service des projets
http://jmvanel.free.fr/ ===) CV, software resources

Mes journaux:
- sujets généraux en Français: http://jmvanel.free.fr/Block-note.html
- sujets informatiques en Français: http://jmvanel.free.fr/notes-informatiques.html
- computer science diary : http://jmvanel.free.fr/computer-notes.html

Worldwide Botanical Knowledge Base
http://wwbota.free.fr/ 
test XML query engine: http://jmvanel.free.fr/protea.html




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bug in constraint on constructed nodes

Pierrick Brihaye-2
Hi,

Jean-Marc Vanel wrote:

>> What's the point here ? What extensions to XQuery specs can be
>> imagined ? Personally, I can't see.
>
> The "tolerant to undeclared conversions" mode could be a non-default mode.

Mmmh... Yet another XQuery dialect ? Who has a strong enough backbone to
assume this ?

> I fear that if eXist suddenly becomes stringent some people's
> application might break.

Yes :-( That may be, however, the price to pay for eXist community to be
fruitful and multiply...

> So this "tolerant to undeclared conversions" mode could be a migration
> path.

Frankly, is it a good example to let people think that an attribute
*node* has a string representation *by default* ? I don't think so...

>> However, eXist already does have "extensions" that are definitely not
>> compliant with the specs : its "fulltext operators".
>
> I never liked this syntax. But now there an official W3C alternative:
>
> http://www.w3.org/TR/2005/WD-xquery-full-text-20050404/

I hope I have time to write a paper on this proposal where operators
rule in a western-centric world ;-)

More on this as soon as possible.

Cheers,

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:[hidden email]
+33 (0)2 99 29 67 78


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Loading...