227 lines
6.0 KiB
Plaintext
227 lines
6.0 KiB
Plaintext
head 1.8;
|
|
access;
|
|
symbols;
|
|
locks; strict;
|
|
comment @# @;
|
|
|
|
|
|
1.8
|
|
date 2009.11.25.03.14.36; author GarryJolleyRogers; state Exp;
|
|
branches;
|
|
next 1.7;
|
|
|
|
1.7
|
|
date 2009.11.20.02.45.29; author LeeBelbin; state Exp;
|
|
branches;
|
|
next 1.6;
|
|
|
|
1.6
|
|
date 2007.03.06.17.30.00; author TWikiGuest; state Exp;
|
|
branches;
|
|
next 1.5;
|
|
|
|
1.5
|
|
date 2006.04.25.08.28.15; author GregorHagedorn; state Exp;
|
|
branches;
|
|
next 1.4;
|
|
|
|
1.4
|
|
date 2004.06.10.06.36.26; author GregorHagedorn; state Exp;
|
|
branches;
|
|
next 1.3;
|
|
|
|
1.3
|
|
date 2004.05.24.08.26.53; author GregorHagedorn; state Exp;
|
|
branches;
|
|
next 1.2;
|
|
|
|
1.2
|
|
date 2004.02.09.19.14.42; author GregorHagedorn; state Exp;
|
|
branches;
|
|
next 1.1;
|
|
|
|
1.1
|
|
date 2004.02.09.15.48.00; author JacobAsiedu; state Exp;
|
|
branches;
|
|
next ;
|
|
|
|
|
|
desc
|
|
@none
|
|
@
|
|
|
|
|
|
1.8
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@%META:TOPICINFO{author="GarryJolleyRogers" date="1259118876" format="1.1" version="1.8"}%
|
|
%META:TOPICPARENT{name="StoredIdentificationKeys"}%
|
|
---+!! %TOPIC%
|
|
|
|
I noticed that there is a unique_key constraint on Key/Label/Representation/Text .
|
|
This means that two Keys in the same Document cannot have the same text description.
|
|
Two versions of our PLDs(which we are getting ready to convert to SDD) have exactly the
|
|
same descriptive text.
|
|
|
|
Can anybody clarify?
|
|
|
|
-- Main.JacobAsiedu - 09 Feb 2004
|
|
|
|
---
|
|
|
|
Since I am responsible, let my try to explain my reasoning:
|
|
|
|
How can two different things have the same label, if the label is the only thing that enables a user to make a distinction among the objects? Imagine a scenario, where you list all available keys on your system and the user may select the one she or he is going to use. You could list the label PLUS an ID, but I find this not very helpful. The ID tells the user nothing, it will still be confusing. Also I think it is good practice to have separate machine and human readable keys and not bother humans with machine keys.
|
|
|
|
If there is a difference between the keys (including versions) you currently have to include that in the label text. What would your solution be? How would you guarantee that differnent objects can be distinguished in the user interface?
|
|
|
|
For conversion routines, I suggest that if they detect a duplication, they attempt to add a note including a random number. That allows to delay clean-up up to a later time, rather than having to deal with it immediately or receive failure-errors. I would, however, suggest a text like: "[Please edit the label; random code 62378463 was added by conversion routine to prevent duplicate]". That is my solution, many others are possible.
|
|
|
|
BTW: the xml schema identity constraint allows two audiences with the same label text for a single key, or even:
|
|
<verbatim>
|
|
Key 1
|
|
audience="en" Text="Fungi"
|
|
audience="de" Text="Pilze"
|
|
Key 2
|
|
audience="en" Text="Mushrooms"
|
|
audience="de" Text="Fungi"
|
|
</verbatim>
|
|
|
|
-- Gregor Hagedorn - 09 Feb 2004
|
|
|
|
---
|
|
|
|
%META:TOPICMOVED{by="GregorHagedorn" date="1086849386" from="SDD.UniqueConstraintOnKeyLabelRepresentationText" to="SDD.ResolvedTopicUniqueConstraintOnLabels"}%
|
|
@
|
|
|
|
|
|
1.7
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="LeeBelbin" date="1258685129" format="1.1" reprev="1.7" version="1.7"}%
|
|
d7 1
|
|
a7 1
|
|
Two versions of our PLDs(which we are getting ready to convert to BDI.SDD) have exactly the
|
|
@
|
|
|
|
|
|
1.6
|
|
log
|
|
@Added topic name via script
|
|
@
|
|
text
|
|
@d1 2
|
|
a4 2
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1145953695" format="1.0" version="1.5"}%
|
|
%META:TOPICPARENT{name="StoredIdentificationKeys"}%
|
|
d7 1
|
|
a7 1
|
|
Two versions of our PLDs(which we are getting ready to convert to SDD) have exactly the
|
|
d34 1
|
|
a34 1
|
|
-- Gregor Hagedorn - 09 Feb 2004
|
|
@
|
|
|
|
|
|
1.5
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 2
|
|
@
|
|
|
|
|
|
1.4
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 33
|
|
a33 33
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1086849386" format="1.0" version="1.4"}%
|
|
%META:TOPICPARENT{name="GuidedKeys"}%
|
|
I noticed that there is a unique_key constraint on Key/Label/Representation/Text .
|
|
This means that two Keys in the same Document cannot have the same text description.
|
|
Two versions of our PLDs(which we are getting ready to convert to SDD) have exactly the
|
|
same descriptive text.
|
|
|
|
Can anybody clarify?
|
|
|
|
-- Main.JacobAsiedu - 09 Feb 2004
|
|
|
|
---
|
|
|
|
Since I am responsible, let my try to explain my reasoning:
|
|
|
|
How can two different things have the same label, if the label is the only thing that enables a user to make a distinction among the objects? Imagine a scenario, where you list all available keys on your system and the user may select the one she or he is going to use. You could list the label PLUS an ID, but I find this not very helpful. The ID tells the user nothing, it will still be confusing. Also I think it is good practice to have separate machine and human readable keys and not bother humans with machine keys.
|
|
|
|
If there is a difference between the keys (including versions) you currently have to include that in the label text. What would your solution be? How would you guarantee that differnent objects can be distinguished in the user interface?
|
|
|
|
For conversion routines, I suggest that if they detect a duplication, they attempt to add a note including a random number. That allows to delay clean-up up to a later time, rather than having to deal with it immediately or receive failure-errors. I would, however, suggest a text like: "[Please edit the label; random code 62378463 was added by conversion routine to prevent duplicate]". That is my solution, many others are possible.
|
|
|
|
BTW: the xml schema identity constraint allows two audiences with the same label text for a single key, or even:
|
|
<verbatim>
|
|
Key 1
|
|
audience="en" Text="Fungi"
|
|
audience="de" Text="Pilze"
|
|
Key 2
|
|
audience="en" Text="Mushrooms"
|
|
audience="de" Text="Fungi"
|
|
</verbatim>
|
|
|
|
-- Gregor Hagedorn - 09 Feb 2004
|
|
|
|
@
|
|
|
|
|
|
1.3
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1085387213" format="1.0" version="1.3"}%
|
|
d36 1
|
|
@
|
|
|
|
|
|
1.2
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1076354082" format="1.0" version="1.2"}%
|
|
d23 1
|
|
a23 1
|
|
|
|
d30 3
|
|
d34 1
|
|
a34 1
|
|
Gregor Hagedorn - 09 Feb 2004
|
|
@
|
|
|
|
|
|
1.1
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="JacobAsiedu" date="1076341680" format="1.0" version="1.1"}%
|
|
d10 9
|
|
d20 13
|
|
a32 1
|
|
-- Main.JacobAsiedu - 09 Feb 2004
|
|
@
|