XPath to enforce document order

[Phlip]

XMLers:

Here's my XPath:

//form[
./descendant::fieldset[
./descendant::legend and
./descendant::li[
./descendant::label and
./descendant::input ]
]
]

Its purpose is unit tests to assert that HTML has certain elements and
attributes (not shown).

I want it to fail if the <li> appears above the <legend>, in document order. Or
if the <label> appears below the <input>. Any ideas?

libxml2, 2.6.32.dfsg-4ubuntu1.1, BTW... Tx!

 

[Philippe Poulard]

Phlip a écrit :

XMLers:

Here's my XPath:

//form[
./descendant::fieldset[
./descendant::legend and
./descendant::li[
./descendant::label and
./descendant::input ]
]
]

Its purpose is unit tests to assert that HTML has certain elements and
attributes (not shown).

I want it to fail if the <li> appears above the <legend>, in document
order. Or if the <label> appears below the <input>. Any ideas?

Hi,

This is a job for WUnit :
http://reflex.gforge.inria.fr/wunit.html
http://reflex.gforge.inria.fr/wunit-quick-start.html

libxml2, 2.6.32.dfsg-4ubuntu1.1, BTW... Tx!

--
Cordialement,

///
(. .)
--------ooO--(_)--Ooo--------
| Philippe Poulard |
-----------------------------
http://reflex.gforge.inria.fr/
Have the RefleX !

 

[Phlip]

Phlip a écrit :

XMLers:

Here's my XPath:

//form[
./descendant::fieldset[
./descendant::legend and
./descendant::li[
./descendant::label and
./descendant::input ]
]
]

Its purpose is unit tests to assert that HTML has certain elements and
attributes (not shown).

I want it to fail if the <li> appears above the <legend>, in document
order. Or if the <label> appears below the <input>. Any ideas?

This is a job for WUnit :

Please don't make my question look answered in the forum. I'm not the
user-programmer testing a page, I'm the vendor-programmer writing an assertion,
so I actually need an answer.

And Ruby on Rails hardly needs a new system to mock the web server and browser.
My assertion does not require the incredible verbosity of XSL. Good luck getting
XSL, or Java, to look like this:

assert_xhtml do
h2 'ACH Sales'
select! :size => SaleController::LIST_SIZE do
option names[1]
option names[0]
end
end

We just write the names and values of our target HTML elements into the block.

 

[Martin Honnen]

Here's my XPath:

//form[
./descendant::fieldset[
./descendant::legend and
./descendant::li[
./descendant::label and
./descendant::input ]
]
]

Its purpose is unit tests to assert that HTML has certain elements and
attributes (not shown).

I want it to fail if the <li> appears above the <legend>, in document
order. Or if the <label> appears below the <input>. Any ideas?

Maybe
//form[
descendant::fieldset[
descendant::legend[
following-sibling::*[
descendant-or-self::li[
descendant::label[
following-sibling::*[
descendant-or-self::input
]
]
]
]
]
]

 

[Richard Tobin]

Please don't make my question look answered in the forum.

What does this mean? How does a question "look answered"? Are you
suggesting that people shouldn't reply to Usenet postings unless they
are giving the exact answer you want?

-- Richard

 

[Richard Tobin]

I want it to fail if the <li> appears above the <legend>, in document
order. Or if the <label> appears below the <input>. Any ideas?

[/QUOTE]

Maybe
//form[
descendant::fieldset[
descendant::legend[
following-sibling::*[
descendant-or-self::li[
descendant::label[
following-sibling::*[
descendant-or-self::input
]
]
]
]
]
]

Not that this just checks for the existence of elements in the right
order. It doesn't prevent there *also* being an <li> before the
<legend>.

-- Richard

 

[Phlip]

What does this mean? How does a question "look answered"? Are you
suggesting that people shouldn't reply to Usenet postings unless they
are giving the exact answer you want?

My bad - I'm familiar with higher volume forums, where I (for one) tend to skip
the questions with a Re tag indicate someone answered. This, in turn, reduces
the quality of answers if the first answer was spurious.

I will try Martin's suggestion; ignoring the other <li> tag is okay if the
terminal paths typically have attributes (not shown) that pin them down.

The goal is if an assertion puts <select><option> content in collating order,
for example, they must run in that order in the View!

 

[Martin Honnen]

path = "//fieldset[
descendant::legend[
following-sibling::*[
descendant-or-self::li[
descendant::label[
following-sibling::*[
descendant-or-self::br[
following-sibling::*[
descendant-or-self::input ] ] ] ] ] ] ] ]"

Problem: Here's the sample input:

<fieldset>
<legend>Personal Information</legend>
<ol>
<li id="control_user_first_name">
<label for="user_first_name">First name</label>
<input type="text" name="user[first_name]" id="user_first_name" />
<br/>
</li>
</ol>
</fieldset>

Notice the <br/> is below the <input>, not above it.

Ironically, I can move other elements around and successfully fail the
query.

Bug in libxml2? Pilot error? Gap in the language specification?

When I evaluate your XPath expression against the sample XML you posted
then it returns an empty node-set. Tested with the XPath tool in jEdit's
XML and XSLT/XPath plugin which is based on Xalan Java.

I don't see why it should find a node as the 'br' element has no
following-sibling::* element at all.

Thus if libxml2 with that expression and XML input returns a non-empty
node-set then I think it has a bug.

 

[Phlip]

Thus if libxml2 with that expression and XML input returns a non-empty

node-set then I think it has a bug.

Gee - I usually love to watch the results when _other_ people push the
envelop... (-:

Tx for the manual test!

I will see if my intermediate library (Nokogiri) is calling libxml2's HTML
parser, and will upgrade to XML and see if that fixes things...