HasTag anomalies

[Paolo F Cantoni]

The HasTag(tagname) query method ONLY evaluates to true if the tag has a value, not if it just exists.  Which I submit is contrary to the documentation:
"Evaluates to true if the associated element has a tag with the name tagname."

Perversely, HasTag(tagname,””) will  fire if the tag has an empty (null) value or EVEN if the tag does not exist, which again, I submit is contrary to the documentation:
"If the second parameter tagvalue is provided, the tag tagname must be present, and the value of the tag has to be equal to tagvalue for the method to evaluate to true."

Reported,
Paolo

[qwerty]

As long as Sparx will proudly clinch to their own "language" inventions (namely shape script and code generation) rather than adopting a commonly used language, we need to get used to those anomalies. So likely forever

q.

[Glassboy]

The HasTag(tagname) query method ONLY evaluates to true if the tag has a value, not if it just exists.  Which I submit is contrary to the documentation:
"Evaluates to true if the associated element has a tag with the name tagname."

To be a pedant it doesn't exist if it is null, the only thing that exists is a descriptor.  Null has been described as the worst mistake in computer science, and the arguments for that position all seem to be true.

Perversely, HasTag(tagname,””) will  fire if the tag has an empty (null) value or EVEN if the tag does not exist, which again, I submit is contrary to the documentation:
"If the second parameter tagvalue is provided, the tag tagname must be present, and the value of the tag has to be equal to tagvalue for the method to evaluate to true."

Obviously does null equal null will evaluate as true.  See previous point about null.

[Paolo F Cantoni]

The HasTag(tagname) query method ONLY evaluates to true if the tag has a value, not if it just exists.  Which I submit is contrary to the documentation:
"Evaluates to true if the associated element has a tag with the name tagname."

To be a pedant it doesn't exist if it is null, the only thing that exists is a descriptor.  Null has been described as the worst mistake in computer science, and the arguments for that position all seem to be true.

Perversely, HasTag(tagname,””) will  fire if the tag has an empty (null) value or EVEN if the tag does not exist, which again, I submit is contrary to the documentation:
"If the second parameter tagvalue is provided, the tag tagname must be present, and the value of the tag has to be equal to tagvalue for the method to evaluate to true."

Obviously does null equal null will evaluate as true.  See previous point about null.

Let's hear it for Pedantry!

I absolutely agree on NULL.

However, given the definition of NULL (that is, NOT being a value), one can't use equality with null, one can only use IsNull().

Further, it IS the case that a Tagged Value consists of two parts:  The Value (the primary concept) and the Tag (Descriptor/Identifier).  The problem is that the Tag can exist in EA without a Value.  This would appear to be a conceptual defect.

One should not be allowed to create a tagged value without supplying and maintaining a value.  Then the documentation can specify:
HasTag(tagname) will evaluate to true if the Tagged Value tagname exists (regardless of the assigned value).
HasTag(tagname, tagvalue) will evaluate to true if the value of the tagname is tagvalue.

Now it works.

If EA insists on allowing tags with empty/null values, then the documentation needs to be adjusted and the code updated since the tag can exist without the value (and so, I guess, isn't a tagged value  )

Paolo

[Glassboy]

One should not be allowed to create a tagged value without supplying and maintaining a value.  Then the documentation can specify:
HasTag(tagname) will evaluate to true if the Tagged Value tagname exists (regardless of the assigned value).
HasTag(tagname, tagvalue) will evaluate to true if the value of the tagname is tagvalue.

I agree.  It should be a zero-length string, which is different from null (apparently not in older versions of Oracle tho).

[Paolo F Cantoni]

One should not be allowed to create a tagged value without supplying and maintaining a value.  Then the documentation can specify:
HasTag(tagname) will evaluate to true if the Tagged Value tagname exists (regardless of the assigned value).
HasTag(tagname, tagvalue) will evaluate to true if the value of the tagname is tagvalue.

I agree.  It should be a zero-length string, which is different from null (apparently not in older versions of Oracle tho).

Ah...

I didn't mean that an empty (zero length) string was a value.  It's another extrinsic and should be tested with IsEmpty() - I will allow ,however, that ="" is the equivalent of IsEmpty().  However, in the case of the Tagged Value setting a value to «Empty» string should cause the Tag to be purged (as with setting the value to «Null».

[Eve]

However, in the case of the Tagged Value setting a value to «Empty» string should cause the Tag to be purged (as with setting the value to «Null».

I strongly disagree. Even if your methodology doesn't allow tagged values with an empty value that is not going to be the case everywhere.

At a conceptual level, (and the entire basis of this thread) there is a difference between an empty value (eg string or set), missing value (null) or a missing container.

Null has been described as the worst mistake in computer science, and the arguments for that position all seem to be true.

I'd be interesting is seeing those arguments. I'd say the concept of a null value is essential to computer science.

[Paolo F Cantoni]

However, in the case of the Tagged Value setting a value to «Empty» string should cause the Tag to be purged (as with setting the value to «Null».

I strongly disagree. Even if your methodology doesn't allow tagged values with an empty value that is not going to be the case everywhere.

At a conceptual level, (and the entire basis of this thread) there is a difference between an empty value (eg string or set), missing value (null) or a missing container.

Null has been described as the worst mistake in computer science, and the arguments for that position all seem to be true.

I'd be interesting is seeing those arguments. I'd say the concept of a null value is essential to computer science.

You're allowed to be wrong...   

Seriously though, it DOES revolve around how language works... 

Is an Empty string a Value - pretty clearly not.  If it is, then how?

In the term "Tagged Value", the word "Tagged" is an adjective qualifying the noun "Value".  Consequently we are talking about Values not Tags (the potential container). A Value cannot hold a non-Value.  Since Empty is a non-value, it can't be meaningfully held by a "Tagged Value".  If you wanted to allow Tags to hold empty strings (which might well be useful), then they should be called Tags not Tagged Values.  A Tag IS NOT a Tagged Value!  As you say, it is a container for a Tagged Value.

In the words of GBS "Madam, we've established what you are, we're just arguing the price..."

We allow the use of Null and Empty in situations where we cannot control input to the requisite degree to maintain conceptual consistency.  For example: A mandatory attribute that allows null or empty IS, by definition, an optional attribute.  We should not confuse the practical necessities with the correct conceptualisation.

[Geert Bellekens]

Paolo,

I'm not interested in arguing about the theoretical concepts, but from a practical standpoint I would not like to see my empty tagged values be purged by EA.

The fact that we define a set of tagged values on a stereotype allows us to control what metadata a user can/must fill in on that particular type of element.

Purging the empty tagged values would make that impossible as the user wouldn't see them anymore.

So let's leave the tagged values handling in EA as it is now, and maybe only fix the shapescript issue at hand.

Geert

[Glassboy]

However, in the case of the Tagged Value setting a value to «Empty» string should cause the Tag to be purged (as with setting the value to «Null».

I strongly disagree. Even if your methodology doesn't allow tagged values with an empty value that is not going to be the case everywhere.

At a conceptual level, (and the entire basis of this thread) there is a difference between an empty value (eg string or set), missing value (null) or a missing container.

The analogy is the Axiom of the empty set.

Null has been described as the worst mistake in computer science, and the arguments for that position all seem to be true.

I'd be interesting is seeing those arguments. I'd say the concept of a null value is essential to computer science.

The article that first brought it to my attention is here, but if you google there's plenty of discussion of it.

[Paolo F Cantoni]

Paolo,

I'm not interested in arguing about the theoretical concepts, but from a practical standpoint I would not like to see my empty tagged values be purged by EA.

The fact that we define a set of tagged values on a stereotype allows us to control what metadata a user can/must fill in on that particular type of element.

Purging the empty tagged values would make that impossible as the user wouldn't see them anymore.

So let's leave the tagged values handling in EA as it is now, and maybe only fix the shapescript issue at hand.

Geert

Geert,

There is actually, a practical result of my (theoretical) argument...  You are tackling the practical problem of how do we indicate an optional tagged value when all you can define are mandatory ones?  As you saw in my argument, an mandatory attribute allowing an empty or null value is, by definition, an optional attribute.

Unfortunately, in the current MDG definition, you can ONLY define mandatory Tagged Values!  If, however, you allowed the (theoretically) correct ability to define optional Tagged Values in the MDG, then if they were defined for a metatype at the MDG level, they could be displayed in the Tagged Value Window - just as at present - but with rendering to indicate the value wasn't (yet) present.  They would NOT be created in the model until a value was supplied.  It would improve the rigour of the model, as well as saving unneeded space.

Your (and my) practical response to the current theoretically incorrect implementation - I believe, just goes to prove my point.    As I mentioned, I also use non-metatype related Tagged Values  (that is, NOT specified in the MDG against the metatype) to get around the problem.

Paolo

[Glassboy]

There is actually, a practical result of my (theoretical) argument...  You are tackling the practical problem of how do we indicate an optional tagged value when all you can define are mandatory ones?  As you saw in my argument, an mandatory attribute allowing an empty or null value is, by definition, an optional attribute.

No it isn't.  An empty value conveys meaning in exactly same way as a non-empty value.  At a very crude level it says the information does not exist or is not known.  That information helps us evaluate the completeness of what we are modeling.

The descriptor existing but not the value only says that tagged values were poorly implemented.

[Paolo F Cantoni]

There is actually, a practical result of my (theoretical) argument...  You are tackling the practical problem of how do we indicate an optional tagged value when all you can define are mandatory ones?  As you saw in my argument, an mandatory attribute allowing an empty or null value is, by definition, an optional attribute.

No it isn't.  An empty value conveys meaning in exactly same way as a non-empty value.  At a very crude level it says the information does not exist or is not known.  That information helps us evaluate the completeness of what we are modeling.

The descriptor existing but not the value only says that tagged values were poorly implemented.

Depends on the semantics you apply to the two extrinsics:  Null (or «Nothing» ) and Empty (or «Missing»); not to mention «Unknown».  You can't tell which is meant and certainly you can't assign both meanings to the one non-value.

As you may know, I'm a great supporter of extrinsics but they can't be universally applied.  This being a case in point.  In this case, if the Tagged Value has no value, it conceptually doesn't exist (I think we're agreed on that). I don't think any other interpretation is allowed.  What the non-existence of the Tagged Value means for the Element depends on the nature of the Element.  If I want the Tagged Value to communicate extrinsic concepts (about the property that the Tagged Value is representing), then the value domain of the Tagged Value is separated into intrinsic and extrinsic values.  Null or Empty are NOT permitted.

We can agree that TVs are poorly implemented. 

Paolo

[Glassboy]

Depends on the semantics you apply to the two extrinsics:  Null (or «Nothing» ) and Empty (or «Missing»); not to mention «Unknown».  You can't tell which is meant and certainly you can't assign both meanings to the one non-value.

This is where I disagree I think both «Missing» and «Unknown» are part of your test for completeness, and in practical terms missing equals unknown anyway.  It's just slightly more nuanced.

[Paolo F Cantoni]

Depends on the semantics you apply to the two extrinsics:  Null (or «Nothing» ) and Empty (or «Missing»); not to mention «Unknown».  You can't tell which is meant and certainly you can't assign both meanings to the one non-value.

This is where I disagree I think both «Missing» and «Unknown» are part of your test for completeness, and in practical terms missing equals unknown anyway.  It's just slightly more nuanced.

Whoops!  As per Helsinki, I should have defined my terms:
«Empty», «Missing», «Not present»   There should be a value, but none was provided
«Unknown»   There is a value but we don't know what it is
«None», «No one», «Nothing»      There is NO Value
«Not applicable»   NO value can be applied

are just some of the standard extrinsic definitions I use.

The difference between «Nothing» and «Unknown» is what got me started on the "Extrinsics Lark" in the late 70s after Reading J.R.Abrial's "Data Semantics".  It is used to distinguish: " I know you nave no spouse"; from:  "I know you have a spouse, but I don't know who they are".

Anyway, we can agree to disagree. 

Paolo