Are specs intended to be explicit or implicit?

This is first a question, and then depending on the answer may turn into a proposal. I'd like to understand the current intentions first.

I'm just beginning to work with xeto, so I appreciate your patience if these are dumb questions :D

Explicit Workflow

My idea of an explicit workflow is the following:

-Define specs in a lib
-Build equips/points
-Assign each equip/point a specific and permanent spec 
-Equips/points auto-inherit spec attributes (TAGS AND POINTS)

The user essentially says this equip should match this spec. This approach has numerous advantages:

• specs are more easily assignable and digestible than tag combinations
• you can validate against the given spec, even if tags are changed or ommitted on the equip/point
• you can auto-inherit any changes made to the spec

This is great. However, I have a major concern with this approach. It requires explicit specs for every single unique combination of AHU extensions. Even if there are only 10 extensions, that evaluates to over 1,000 unique specs to handle each combination. If those have to be pre-defined in a lib to be usable, its a non starter.

Implicit Workflow

By contrast, an implicit workflow looks like:

-Define specs 
-Build equips/points
-Equips/points auto-inherit attributes (EXCEPT tags, since they are manually defined)

Now instead of telling, the user is asking what specs does this equip fit? so they can validate other (non-tag) attributes. Simply adding a tag will auto-inherit new specs and attributes. No need for 1,000 unique specs.

This way, you can

• still validate (at least using the newly fitted specs)
• quickly add components to equips and validate newly required additions
• avoid having to create every single unique combination of specs in a predefined lib

Ideally

Ideally (and I think this is the case), xeto will allow for both implicit and explicit approaches. I think having tools for both makes sense - even if you have to choose between them. I can think of a few ways to accomplish this:

• Allowing "local" specs outside of a lib. If the explicit spec tag could handle a list of specs (and could compile attributes without duplications) that would work well
• Having some sort of validationMethod "choice" to use explicit specs vs auto-inherit based on tagging.

Hi James,

I probably didn't follow your questions 100%, but from a broad perspective the answer is yes Xeto will support both implicit and explicit validation.

Explicitly you can annotate an entity with the "spec" tag which is a Ref with the spec's qualified name. This informs the system that the entity is expected to conform to that spec. This is nominal typing of the entity. In the Haxall implementation, you can use the fitsExplain() function with a null spec and it will validate the input dicts against their spec tag (validate them against what they say they are).

Implicitly you can use structural typing to validate against any spec. Or you can run queries to see what specs your entities fit. So there is a lot of flexibility in how you use those features to build up validation routines.