On 27/08/2013 18:20, Diego Bosc? wrote:
> The problem with this rules come with the (explicit or implicit)
> specialization of single attributes. take this example:
>
> ELEMENT[at0009] occurrences matches {0..1} matches { -- Position
> value existence matches {0..1}
> matches {
> DV_TEXT occurrences
> matches {0..1} matches {*}
> }
> }
>
> What happens if a DV_TEXT is added on the specialization? Does it need
> at code? Do we consider the rule to be applied to the archetype +
> parent or only to the archetypes? Do we need to add an at-code also to
> the parent?
If it were added in a specialisation with no code, it would be assumed
to be a redefinition of an existing DV_TEXT constraint, assuming there
was one. If added with a code, the post flattening validation (phase 3)
in the current ADL workbench would need to detect this. Right now it
doesn't have checks in that phase for this. I'll have to run this
example through the compiler to see what it does.
> This would need either a rewriting of the rule to state the issue with
> flat archetypes or a potential problem if an at-code is not specified.
good point; the rules should specify that they apply to flattened
archetypes, which means that ids are required even if each
specialisation child introduces only one alternative. I'll fix this in
the spec.
>
> Another use case is when valid children types are part of the same
> class hierarchy (no need for specialization). Do we need at-codes when
> we create siblings such as DV_TEXT and DV_CODED_TEXT?
according to the current rules (see my previous post), yes. I would
actually still rather avoid this, and am still thinking about it...
> If we have several different data types, such as DV_BOOLEAN,
> DV_QUANTITY, and DV_TEXT and then we want to add a DV_CODED_TEXT,
> which one of the data types gets an at-code? all? only the text ones?
> none?
according to the previous rules, none. But DV_CODED_TEXT would be
treated as a preferential constraint over DV_TEXT due to the RM
inheritance relationship. It would be up to apps and tools to make use
of that.
>
> Again, rewording/clarification is needed or problems may occur.
yes - I doubt that we are at the final version of the wording on this -
but have a look at the new version and see what you think.
>
> What is so wrong about having at-codes in every class of the archetype
> with no ontology definition for that code?
interesting question - so far (10 years!) we have always treated an
at-code as something that is in the ontology. At the moment no tools at
all would handle the assumption that only some codes had definitions; it
would raise questions: how do you know which things need definitions and
which don't? My guess is that there would need to be a special
definition that is connected to the at-codes you want to have no
definitions, which would complicate the archetype ontology section
structure.
- thomas
