How to allow for a blank "Date" as a tagged value type

[Ron Beernink]

When you specify a tagged value with a type of "Date" there seems to be no way to allow for it to be blank; for example for when the date is not known or is not applicable for the element object in question.  Is that correct and if so, is there an alternative option?   I did look at the "Custom" type but it does not force a set date format (e.g. "dd/mm/yy") template option.

Ron

[qwerty]

The same when you have a drop down. It starts with blank (if you don't define a default). Once you assigned a value from the drop down there is no way back. The "Sparxian solution": create an empty value like "None" since you can not add an empty value to an enum you end up with this. Send a feature request or live with it.

q.

[Geert Bellekens]

For enum tags we always add a value "TBD" (To Be Defined) to explicitly indicate the fact that the value hasn't been filled in yet.

I don't think that works for dates though.

Geert

[Uffe]

Hi Ron,

There is something called masked tagged value types, which you could (possibly) use.
But it's pretty ancient stuff, it doesn't look very good, and you'd have to write scripts to sanity-check the data against dates like 31/02/2023 (or even 45/27/1996).

/Uffe

[qwerty]

Can one get that into a profile definition?

q.

[Uffe]

The same when you have a drop down. It starts with blank (if you don't define a default). Once you assigned a value from the drop down there is no way back.

Well not go go all Paolo on you there Q, but IMO that's actually right. An enumeration type is one-of-a-set, it's not nullable. And that's consistent with the behaviour of Dates and most other structured tag types (except RefGUID, which you can set to <none> in the selector dialog).

Unless the standard actually prohibits it, I think it should be possible to specify that a structured tagged value should be nullable.
In the structured tag value definition this could be implemented with a new reserved word Nullable=True|False;, with the tagged value connector it's a question of whether the multiplicity includes 0.
If not nullable, current behaviour; if nullable, you would be able to clear the tagged value.

Certainly EA doesn't have any problems with tagged values actually being empty, so this shouldn't be impossibly hard to do.

/Uffe

[Uffe]

Can one get that into a profile definition?

Not that I'm aware, but the OP didn't say it was a profile, just a tagged value definition.

/U

[Uffe]

Can one get that into a profile definition?

Not that I'm aware, but the OP didn't say it was a profile, just a tagged value definition.

Although I wouldn't be surprised if you could by creating a «metaclass» Mask and putting the mask definition of the third line of a <memo> tagged value and drawing a Realization backwards from your «stereotype» class. It's EA, after all.

[Paolo F Cantoni]

The same when you have a drop-down. It starts with blank (if you don't define a default). Once you assigned a value from the drop-down there is no way back.

Well not to go all Paolo on you here Q, but IMO that's actually right. An enumeration type is one-of-a-set, it's not nullable. And that's consistent with the behaviour of Dates and most other structured tag types (except RefGUID, which you can set to <none> in the selector dialog).

Unless the standard actually prohibits it, I think it should be possible to specify that a structured tagged value should be nullable.
In the structured tag value definition this could be implemented with a new reserved word Nullable=True|False;, with the tagged value connector it's a question of whether the multiplicity includes 0.
If not nullable, current behaviour; if nullable, you would be able to clear the tagged value.

Certainly, EA doesn't have any problems with tagged values actually being empty, so this shouldn't be impossibly hard to do.

/Uffe

A couple of issues here.  Firstly, Uffe is correct in saying that an enumeration type is notionally not nullable.  But where data entry is concerned, there should always be the possibility of extrinsic^[1] values to handle data entry concepts (uninitialised, missing, removed etc.).  This can be accomplished for most tag value types (and their equivalent datatypes).

Dates aren't an enumeration set, because they have a range.  But that having been said, it is still necessary to handle extrinsic values.  Where the dates are stored as strings (such as in EA tags), then string captions for the extrinsics can be allowed.  Where the dates are not stored as strings (even numeric strings), then specific dates can be used to represent the extrinsics.  Over the decades, I've standardised these values and they seem to work quite well.  I can share if asked.

As to whether the Standard allows Nulls...  If it doesn't, then Sparx is in violation (see the discussion regarding Tag default values).  So we should assume that it doesn't explicitly forbid them.

As a Data Architect, I abhor NULLS, but if you really insist on allowing them, then it should be explicit as suggested above.

Paolo
^[1] Extrinsic values are, by definition, not nulls.

[qwerty]

I guess that the issue is that EA starts with a Null in the value for enums. That should not be allowed and it must be required to have a default from the enum list (EA allows any string for the initial value). OTOH you could see the empty value as "never touched". Just needs documentation.

q.