You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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:
X
adds a vendor-specific functionfoo()
foo()
is generally useful and adopts it as a standard functionfoo()
as implemented byX
foo()
is now in direct conflict withfoo()
inX
's implementation; the users ofX
suffers from queries breakingTo avoid this situation, the namespace part of a function name could be used; the function
foo()
would be implemented asX.foo()
inX
's implementation, and when adopted in the standard as justfoo()
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).The text was updated successfully, but these errors were encountered: