One of the most powerful features of rule modeling in Corticon is the ability to create multiple filtered views of a collection of data. The underlying data is the same, but each view is filtered to only surface the entities which match your filter criteria. For example, given collections of students and courses, you might use filtered views for students based on different combinations of credits achieved and enrolled major. For courses, you might have filtered views based on course requirements and location. These views could be used by rules to provide course recommendations to students.

In Corticon, creating filtered views of collections is done using aliases. An alias provides a “logical name” for a filtered view of a collection. Corticon.js simplifies rule writing by only requiring alias on collections when you want a filtered view. Corticon for Java and .NET require an alias on any usage of a collection in a rule.

In Corticon for Java and .NET, these are invalid expressions because they use collections without an alias:

But in Corticon.js they are valid:

What’s going on in Corticon.js?

In Corticon.js each of is valid and has a unique meaning

• FlightPlan.cargo->isEmpty: This is the simplest form of collection usage. There is no alias or filter. It is “all cargo”.
• allFlights.cargo->isEmpty: Using the alias “allFlights” but in this context it’s just a short hand notation (not much shorter in this example). It is again “all cargo”
• bigFlights.cargo->isEmpty: Using an “alias” and a filter. The alias identifies the filtered “view” of the collection. This is just cargo with “volume > 1”

This difference in behavior does not impact taking migrating rules written for Java or .NET to JavaScript, but it could impact migrating the other way. To make the rules valid you’d have to use aliases:

With Corticon.js, you don't need to use aliases unless using filtered views.