Challenge: shortest patterns that match everything, nothing | Tech Off

Matthew van Eerde
AKA Maurits

I'm working on a project where I get to use XPath, .NET regular expressions, and SQL LIKE patterns. Lots of fun Smiley

I'm wondering what the shortest possible patterns are in each of these pattern-matching languages that either a) match every expression or b) fail to match every expression.

I've got the "match everything" expressions down for two of them, I think:

// (regex, match everything)
If the null pattern is disallowed (suppose this is javascript) then I'm not sure... /.*/ works, and perhaps /^/ is worth considering.

'%' (LIKE, match everything)

The "match nothing" cases are harder. I've come up with some to beat:

/a\bc/ (regex, match nothing)

'[]' (LIKE, match nothing)

Sven Groot
My name has 9 letters. Coincidence? I think not...

Been thinking about XPath.

Matches everything would be "//node()". Note that "//*" wouldn't work because it matches elements only. However, in .Net I know that "//node()" won't match the xml declaration, although it will match other processing instructions. The xml declaration appears unselectable. I'm not sure if this is defined in the XPath standard or just a .Net quirk.

Insignificant whitespace is also unselectable.

There's no clear cut way to select nothing using XPath. It'd have to be some expression that can't match anything regardless of the document.

The shortest I can think of is "/@*" which matches nothing since the root node is a not an element (it has nodetype Document) so it never has attributes.

Rossj

Sven Groot wrote:
Been thinking about XPath.

Matches everything would be "//node()". Note that "//*" wouldn't work because it matches elements only. However, in .Net I know that "//node()" won't match the xml declaration, although it will match other processing instructions. The xml declaration appears unselectable. I'm not sure if this is defined in the XPath standard or just a .Net quirk.

If you are using the DOM there is no need to use XPath to get the xml decl, so why include it?

Sven Groot
My name has 9 letters. Coincidence? I think not...

Rossj wrote:

Sven Groot wrote: Been thinking about XPath.

Matches everything would be "//node()". Note that "//*" wouldn't work because it matches elements only. However, in .Net I know that "//node()" won't match the xml declaration, although it will match other processing instructions. The xml declaration appears unselectable. I'm not sure if this is defined in the XPath standard or just a .Net quirk.

If you are using the DOM there is no need to use XPath to get the xml decl, so why include it?

If you go by that reasoning, there's no need to use XPath to get any node whatsoever, so why use it at all?

Rossj

Sven Groot wrote:

Rossj wrote:

Sven Groot wrote: Been thinking about XPath.

Matches everything would be "//node()". Note that "//*" wouldn't work because it matches elements only. However, in .Net I know that "//node()" won't match the xml declaration, although it will match other processing instructions. The xml declaration appears unselectable. I'm not sure if this is defined in the XPath standard or just a .Net quirk.

If you are using the DOM there is no need to use XPath to get the xml decl, so why include it?

If you go by that reasoning, there's no need to use XPath to get any node whatsoever, so why use it at all?

Because there is only one xml decl and you know where it is, you've no idea whether any of the nodes in the xpath even exist until you've run the query. I'm not saying this *is* why it doesn't return it, I am just suggesting *why* it may not.