Remove xpath feature/directory from the repo?

[sideshowbarker]

For XPath, we actually have only a single feature in BCD, and the entire content of its MDN article is literally a single sentence:

The self axis indicates the context node itself. It can be abbreviated as a single period (.).

Does that solitary feature — not really even documented in MDN — merit continuing to have its own top-level directory in BCD?

[gsnedders]

There's two arguments given the relative stability of XPath implementations over time, as far as I'm aware everyone has long supported XPath 1, and there's been little-to-no interest in supporting any more recent revision to XPath:

• We should make sure it's all correct and keep it, as the mainteinance burden is near-zero.
• We should remove it, because it provides little value beyond simply making a blanket statement that "document.evaluate supports XPath 1".

[sideshowbarker]

We should remove it, because it provides little value beyond simply making a blanket statement that "document.evaluate supports XPath 1".

Right — and we don’t need to have an entire top-level directory in BCD just to enable that statement to be made.

And to restate what I wrote in the issue description: We’re anyway not even tracking data for XPath1 in BCD — instead we are tracking data for one single thing in XPath1: the self axis — but not for, say, the child axis, following-sibling, etc.

It’s pretty hard to imagine an actual use case where a web developer would just be asking themself, ”I wonder which web browsers support the self axis?”

[Elchi3]

I'd say remove it from BCD.
If someone wants to do a proper compat and documentation project for XPath on BCD and MDN, we can come back to it. What we have right now isn't useful at all as Mike says.

[ddbeck]

I'm happy to see this bit go away. But it would be a breaking change to remove it (since I foolishly included it in the list of semver-protected namespaces). Do we want to keep it around until we have another breaking change to make? Or should we just go ahead as a standalone thing?

[Elchi3]

I think we can wait. It doesn't hurt anyone (and I guess it won't be a breaking change practically because who would rely on this in practice for real?)

[sideshowbarker]

it would be a breaking change to remove it (since I foolishly included it in the list of semver-protected namespaces).
Do we want to keep it around until we have another breaking change to make? Or should we just go ahead as a standalone thing?

I have no strong opinion either way. It’s certainly not urgent but given that there’s some cost (due to it being a breaking change) — I suggest we also remove the xslt directory too, at the same time, per #9826 (rather than having the cost of going through dropping them at separate times).

[ddbeck]

It seemed pretty easy to do, so I opened draft PR #9830 to leave open until we're ready to do a breaking release.