<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
<BR>
<BR>
On Tue, 2008-10-21 at 00:01 -0700, Rushan Chen wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Julian,

Thought I could chime in as I posted the original suggestion for syntax 
extension, which is turning out to be a different function in its final 
shape.

An earlier post here asked for inputs for the syntax options considered:
<A HREF="http://lists.pentaho.org/pipermail/mondrian/2008-October/001473.html">http://lists.pentaho.org/pipermail/mondrian/2008-October/001473.html</A>
(The URL it refers to should be 
<A HREF="http://pub.eigenbase.org/wiki/MondrianOrderFunctionExtension#Syntax_Options)">http://pub.eigenbase.org/wiki/MondrianOrderFunctionExtension#Syntax_Options)</A>

After a few days without new use cases that supports the alternative 
syntax, we decided on adopting a new function name because it is the 
least entangled with the existing Order function and its implementation.

Rushan
</PRE>
</BLOCKQUOTE>
I have just read the discussion about CollationKey vs. OrderSet and I am strongly in favor of CollationKey. I would call it ORDER_KEY, because collation connotes NLS.<BR>
<BR>
Example. The ORDER_KEY property is similar to ORDINAL but only applies to the current level. E.g. [Time].[2008].[October].ORDER_KEY evaluates to 10, [Time].[2009].[July].ORDER_KEY evaluates to 7.<BR>
<BR>
(Aside. And as we know ORDINAL is somewhat broken. If there is no integer ordinal column that numbers every member in every level of a hierarchy, mondrian should construct a compound value that implements java.lang.Comparable and has a sensible toString() and that should get used. But that's a separate topic.)<BR>
<BR>
(Sorry I didn't chime in earlier. I have been even busier than usual, and have not been getting through my email backlog - especially those that contain links to long design discussions.)<BR>
<BR>
In the 'cons' of OrderSet you do not mention that it is against the spirit of MDX to let members evaluate to members, and this is a big one.<BR>
<BR>
A sign of this is in the code - you check whether a member is a measure in order to figure out how to evaluate it. Elsewhere in mondrian (and the MDX language) measures are treated like regular members.<BR>
<BR>
I do not think that this will not necessarily change the underlying implementation. You could recognize usages of the ORDER_KEY property and convert it into a sort key with isMemberValueExp=true. My hunch is that regarding everything as an expression will simplify the implementation, but I will leave that to you.<BR>
<BR>
Julian<BR>
<BR>
</BODY>
</HTML>