Morpho

Morpho substrings XPaths improperly in certain cases when extracting data for the Access wizard, ultimately causing it to unnecessarily punt to the tree editor.

Here are some reproducible cases:

• If there is an 'allow' element for principal 'public', along with 10 or more 'allow' elements for (non-public) principals, Morpho incorrectly parses the 10th one.
• If there is an 'allow' element for principal 'public', Morpho incorrectly parses any 'deny' elements for (non-public) principals.
• If there is a 'deny' element for principal 'public', along with at least one 'allow' element and at least one 'deny' element for (non-public) principals, Morpho incorrectly parses those 'deny' elements.

For a live example of the first case, try to open the Documentation->Access Information interface for this data package:
http://knb.ecoinformatics.org/knb/metacat/krobinson.12.6/nceas

I believe the problem lies at least partly in lines 1304-1305 of AccessPage.java (as of rev 4925). For the cases above, this.xPathRoot.length() isn't actually the right value to pass to the substring statement. Depending on the case, the trimmed XPath ends up either having an extra character at the start, or having its first character truncated.

From stderr.log, here's an example of the first case above (note the extra ']' as the first character of the trimmed nextXPaths):

...
Access: nextXPath = /access/allow¹⁰/principal¹
nextVal = user10
Access: TRIMMED nextXPath = ]/principal¹
Access: nextXPath = /access/allow¹⁰/permission¹
nextVal = read
Access: TRIMMED nextXPath = ]/permission¹
...

And here's an example of the second case (note the missing first letter in the trimmed nextXPaths -- actually, maybe they're missing a leading '/' too?):

...
Access: nextXPath = /access/deny¹/principal¹
nextVal = user09
Access: TRIMMED nextXPath = rincipal¹
Access: nextXPath = /access/deny¹/permission¹
nextVal = read
Access: TRIMMED nextXPath = ermission¹
...