Namespace guidelines for functions and procedures

[Mats-SX]

CIR-2017-255

During oCIG call 5 the issue of potential future conflicts in function names was raised. In particular, the following scenario was expressed as an example:

• A vendor X adds a vendor-specific function foo()
• The oCIG decides that foo() is generally useful and adopts it as a standard function
• The oCIG disagrees with (a detail of) the semantics of foo() as implemented by X
• The standardised function foo() is now in direct conflict with foo() in X's implementation; the users of X suffers from queries breaking

To avoid this situation, the namespace part of a function name could be used; the function foo() would be implemented as X.foo() in X's implementation, and when adopted in the standard as just foo() it would not be in conflict.

Although no procedures are currently part of the standard, the same argument applies to them in the event that any should be accepted into the standard in the future.

Request

The exact form of the namespace part should be standardised so that each vendor can use a unique, consistent namespace for their vendor-specific functions and procedures. These namespace forms would thus be well-known and could be avoided by users when these write their own user-defined functions and procedures.

Suggestions

A reverse domain name descriptor, eg org.neo4j could be utilised -- this could optionally be coupled with the constraint that the specific domain is also owned by the vendor (which guarantees uniqueness via ICANN).