Bugs item #1351516, was opened at 2005-11-08 18:10
Message generated for change (Settings changed) made by boncz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1351516&group_id=56967
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: PF/compiler
Group: Pathfinder CVS Head
Status: Open
Resolution: Later
>Priority: 1
Private: No
Submitted By: Torsten Grust (teggy)
Assigned to: Jens Teubner (teubner)
Summary: PF: attribute after non-attribute content
Initial Comment:
The query
<a>b{attribute c {"d"}}</a>
should yield XQTY0024 (an attribute node cannot be
created after the children of the containing element)
but constructs the element
<a c="d">b</a>
in Pathfinder.
(This is a type checking issue.)
Greetings,
--Teggy
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2009-11-11 19:48
Message:
===================================================================
2009/11/11 - stmane:
pathfinder/tests/BugDay_2005-12-19_0.9.3/Tests/All,1.13.36.1
Disabled test that is bound to fail.
Please re-enable once bug is fixed.
cf.
ID: 1351516 "PF: attribute after non-attribute content"
https://sourceforge.net/tracker/index.php?func=detail&aid=1351516&group_id=56967&atid=482468
===================================================================
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2009-02-16 00:35
Message:
updated TestWeb URLs:
ALG:
http://monetdb.cwi.nl/testing/projects/monetdb/Stable/pathfinder/.mTests103/GNU.64.64.d.1-Fedora8/tests_BugDay_2005-12-19_0.9.3/attribute_after_non-attribute_content.SF-1351516.out.00.html
http://monetdb.cwi.nl/testing/projects/monetdb/Stable/pathfinder/.mTests103/GNU.64.64.d.1-Fedora8/tests_BugDay_2005-12-19_0.9.3/attribute_after_non-attribute_content.SF-1351516.err.00.html
MPS:
http://monetdb.cwi.nl/testing/projects/monetdb/Stable/pathfinder/.mTestsg103/GNU.64.64.d.1-Fedora8/tests_BugDay_2005-12-19_0.9.3/attribute_after_non-attribute_content.SF-1351516.out.00.html
http://monetdb.cwi.nl/testing/projects/monetdb/Stable/pathfinder/.mTestsg103/GNU.64.64.d.1-Fedora8/tests_BugDay_2005-12-19_0.9.3/attribute_after_non-attribute_content.SF-1351516.err.00.html
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2008-01-22 14:39
Message:
Logged In: YES
user_id=572415
Originator: NO
This one is still an issue:
http://monetdb.cwi.nl/testing/projects/monetdb/Current/pathfinder/.mTests103/GNU.64.64.d-Fedora6/tests_BugDay_2005-12-19_0.9.3/attribute_after_non-attribute_content.SF-1351516.out.00.html
http://monetdb.cwi.nl/testing/projects/monetdb/Current/pathfinder/.mTests103/GNU.64.64.d-Fedora6/tests_BugDay_2005-12-19_0.9.3/attribute_after_non-attribute_content.SF-1351516.err.00.html
----------------------------------------------------------------------
Comment By: Martin Kersten (mlkersten)
Date: 2007-11-10 23:36
Message:
Logged In: YES
user_id=490798
Originator: NO
Please, confirm status
----------------------------------------------------------------------
Comment By: Sjoerd Mullender (sjoerd)
Date: 2007-02-19 18:12
Message:
Logged In: YES
user_id=43607
Originator: NO
Is this going to be a "Won't Fix" or what?
----------------------------------------------------------------------
Comment By: Jens Teubner (teubner)
Date: 2006-06-11 12:25
Message:
Logged In: YES
user_id=731390
Sorry, Fabian, I did not.
Our static type inference does indeed need some overhaul.
This bug is one instance of our problems only. It is
definitely not a show-stopper, though, and I marked this as
"Later".
(We do have a student here who claimed interest. But he does
not want to start before the end of the semester. We'll see
...)
----------------------------------------------------------------------
Comment By: Fabian (mr-meltdown)
Date: 2006-06-06 21:08
Message:
Logged In: YES
user_id=963970
Jens, did you ( by chance 0:-) ) do this yourself already?
Feel free to reset flags if not :)
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2006-01-20 10:09
Message:
Logged In: YES
user_id=572415
Thanks, Jens.
I'll temorary reduce the "Priority" until the release is out...
----------------------------------------------------------------------
Comment By: Jens Teubner (teubner)
Date: 2006-01-20 10:01
Message:
Logged In: YES
user_id=731390
I'm afraid not.
It requires fixing the static type inference for XPath
location steps first, which is quite some work to do. We
were hoping to get a student here to work on this typing
stuff. One day I will have to do this myself...
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2006-01-19 23:51
Message:
Logged In: YES
user_id=572415
Jens,
just for the bookkeeping:
I guess, this won't be fixed/fixable for this release (i.e.,
before Sunday)?
----------------------------------------------------------------------
Comment By: Stefan Manegold (stmane)
Date: 2005-12-19 23:32
Message:
Logged In: YES
user_id=572415
BugDay_2005-12-19, stmane: TEST ADDED / FAILURE:
pathfinder/tests/BugDay_2005-12-19_0.9.3/Tests/attribute_after_non-attribute_content.SF-1351516.*
----------------------------------------------------------------------
Comment By: Jens Teubner (teubner)
Date: 2005-11-10 15:55
Message:
Logged In: YES
user_id=731390
I have looked into this, and I've actually prepared
a fix for this in my working copy.
However, committing it would actually break more
than it fixes. Our current implementation of static
typing rules for XPath location steps apparently are
too simplistic.
We basically use the node test in the step as the
step's return type (.../child::text() leads to `text*',
.../child::foo leads to `element foo {...}*', etc.). This,
however, means that .../child::node() will have the
return type `node*', which no longer would be
accepted as the content in an element construction
operator. With my fix, any query of the form
element { ... } { .../node() }
is doomed to fail with a static type error.
What we need before actually implementing the
constraint is a more elaborated typing of XPath
location steps. We should definitely do that
anyway, but it is more than an afternoon's hack :(
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1351516&group_id=56967
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
