Fixes #18, fixes #19.

[AndrewSales]

No description provided.

[tgraham-antenna]

1. The existing schema has line breaks in messages. The schema should be consistent one way or the other. (I'm old-school and favour lines less that 80 characters, plus having to scroll horizontally when looking at code on GitHub is a pain.)
2. The existing sch:assert matches an potentially erroneous superset of what the added sch:assert matches. Should the existing sch:assert just be removed?
3. Changing ../../ to ancestor::sch:pattern/ would make the relationship even more explicit (and save some of us from having to look at the schema to confirm the XPath).

[AndrewSales]

1. The existing schema has line breaks in messages. The schema should be consistent one way or the other. (I'm old-school and favour lines less that 80 characters, plus having to scroll horizontally when looking at code on GitHub is a pain.)

Noted. I favour shorter lines too for readability - it's always possible to pull the code and review it in your preferred environment with indentation of your choosing instead, but perhaps that too introduces a further level of pain.

However, linebreaks in this context are significant. I admittedly didn't remove them elsewhere for consistency, but if we are going into this level of - arguably cosmetic - detail in a pull request that aims to address an issue a user encountered which would otherwise have been caught by the code proposed here, then I'd be inclined to remove them (as well as leading and trailing space) in all asserts in this schema.

2. The existing sch:assert matches an potentially erroneous superset of what the added sch:assert matches. Should the existing sch:assert just be removed?

Yes, OK.

3. Changing ../../ to ancestor::sch:pattern/ would make the relationship even more explicit (and save some of us from having to look at the schema to confirm the XPath).

Another way to have made it clearer would just have been to make the path in sch:rule/@context explicit: sch:pattern/sch:rule/sch:extends[@rule], which makes the hierarchy completely clear.

[tgraham-antenna]

1. The existing schema has line breaks in messages. The schema should be consistent one way or the other. (I'm old-school and favour lines less that 80 characters, plus having to scroll horizontally when looking at code on GitHub is a pain.)

Noted. I favour shorter lines too for readability - it's always possible to pull the code and review it in your preferred environment with indentation of your choosing instead, but perhaps that too introduces a further level of pain.

However, linebreaks in this context are significant. I admittedly didn't remove them elsewhere for consistency, but if we are going into this level of - arguably cosmetic - detail in a pull request that aims to address an issue a user encountered which would otherwise have been caught by the code proposed here, then I'd be inclined to remove them (as well as leading and trailing space) in all asserts in this schema.

I mostly care that it is consistent. It saves the user from even noticing that the file has been edited.

My later thought is that the Schematron was copied straight from Annex B (which you would have already known) and that you might want to format it in whichever way can be pasted straight back into a future Annex B.

1. The existing sch:assert matches an potentially erroneous superset of what the added sch:assert matches. Should the existing sch:assert just be removed?

Yes, OK.

1. Changing ../../ to ancestor::sch:pattern/ would make the relationship even more explicit (and save some of us from having to look at the schema to confirm the XPath).

Another way to have made it clearer would just have been to make the path in sch:rule/@context explicit: sch:pattern/sch:rule/sch:extends[@rule], which makes the hierarchy completely clear.

As you see fit.