368 lines
22 KiB
Plaintext
368 lines
22 KiB
Plaintext
head 1.12;
|
|
access;
|
|
symbols;
|
|
locks; strict;
|
|
comment @# @;
|
|
|
|
|
|
1.12
|
|
date 2009.11.25.03.14.33; author GarryJolleyRogers; state Exp;
|
|
branches;
|
|
next 1.11;
|
|
|
|
1.11
|
|
date 2009.11.20.02.45.25; author LeeBelbin; state Exp;
|
|
branches;
|
|
next 1.10;
|
|
|
|
1.10
|
|
date 2007.03.06.17.30.00; author TWikiGuest; state Exp;
|
|
branches;
|
|
next 1.9;
|
|
|
|
1.9
|
|
date 2006.05.02.13.09.10; author GregorHagedorn; state Exp;
|
|
branches;
|
|
next 1.8;
|
|
|
|
1.8
|
|
date 2006.04.29.19.05.16; author GregorHagedorn; state Exp;
|
|
branches;
|
|
next 1.7;
|
|
|
|
1.7
|
|
date 2006.04.29.14.09.44; author BobMorris; state Exp;
|
|
branches;
|
|
next 1.6;
|
|
|
|
1.6
|
|
date 2006.04.28.09.01.29; author GregorHagedorn; state Exp;
|
|
branches;
|
|
next 1.5;
|
|
|
|
1.5
|
|
date 2006.04.28.07.43.32; author GregorHagedorn; state Exp;
|
|
branches;
|
|
next 1.4;
|
|
|
|
1.4
|
|
date 2006.04.27.09.49.40; author GregorHagedorn; state Exp;
|
|
branches;
|
|
next 1.3;
|
|
|
|
1.3
|
|
date 2006.04.27.02.01.38; author BobMorris; state Exp;
|
|
branches;
|
|
next 1.2;
|
|
|
|
1.2
|
|
date 2006.04.26.06.04.20; author BobMorris; state Exp;
|
|
branches;
|
|
next 1.1;
|
|
|
|
1.1
|
|
date 2006.04.26.04.57.58; author BobMorris; state Exp;
|
|
branches;
|
|
next ;
|
|
|
|
|
|
desc
|
|
@none
|
|
@
|
|
|
|
|
|
1.12
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@%META:TOPICINFO{author="GarryJolleyRogers" date="1259118873" format="1.1" version="1.12"}%
|
|
%META:TOPICPARENT{name="WebHome"}%
|
|
---+!! %TOPIC%
|
|
|
|
b9 should be ignored by all but Gregor, Bob and Jacob.
|
|
|
|
I propose that Kevin begin documenting from b10 when it is released and the release SDD1_1 be whatever results from such small points or disaster fixes that are discovered in b10.
|
|
|
|
|
|
Remarks (that we shouldn't do anything about, having taken the decisions reflected below):
|
|
|
|
---+++Identity constraints and id-attribute
|
|
|
|
* optionality of language and audience attributes
|
|
The cost of this is seen in this scenario: Consider an instance document with, say 300 state labels all 'blue' together with one state 'red' on a character "flower color". An application whose UI is automatically generated from the state list (as all conceivable applications will do), and which does not check the (several combinations of) possible non-uniqueness, will offer 300 choices of 'blue' and one of 'red'. I note, however, that a robust application would probably tolerate this _even_ if it were signalled by a schema validator, unless the application writer chose some kind of normalization strategy that would rewrite a semantically equivalent but valid document, e.g. in this case removing duplicates. -- Main.BobMorris - 26 Apr 2006
|
|
* I propose to use external validation, both to require uniqueness of labels for different objects, and require within any object to have only a single label for any combination of role, language, audience. -- Main.GregorHagedorn - 27 Apr 2006
|
|
* Jacob & Bob propose (tel.) to change xs:key to xs:unique, and change all xs:keyrefs to refer to these xs:unique instead of xs:key. This seems to be a very good idea to more appropriately reflect the optional nature of the id attribute for local (within-document) references. Gregor.
|
|
* Gregor: *I propose furthermore to require all id attributes in a document to be unique.* The within-object class (e.g. character) xs:unique should be maintained and should be the source of keyref validation, thus validating both object reference and type-safe class referencing. Background: the decision to only have within-object class identity constraints dates back to a time when SDD considered id and ref values to be persistent, potentially reflecting database identifiers. However, we have since rejected possible methods to express what kind of identifier is in the id, and decided to rather consider id and ref values as being non-persistent, optionally to be discarded after resolving all references. Under these conditions, it seems more in line with xml-ID usage in other standards (e.g. xhtml) to require document-wide uniqueness. Combining
|
|
|
|
---+++From email exchanges:
|
|
* Bob, Jacob: 1. !UnivariateStatMeasureElaboration/Specification/__FormatPattern vs .../__OrThisInstead. I would go with the !FormatPattern. I think it is strong enough and corresponds to regex support in many programming language libraries. Use it now and see if anyone complains.
|
|
* Gregor: One problem I see is that I do not know how to make this culture specific. XSLT is US-English, so most Europeans (where the US "decimal point" is the comma, and the 1000-separator the period) can not use it for output. But perhaps to make sense to separate formatting structure from culture, and hope that culture is fixed by other means. My proposed changes inside Specification are:
|
|
* Delete the __OrThisInstead
|
|
* Change __FormatPattern to !FormatPattern, change annotation to following:
|
|
* "Format rules as used in the xslt format-number function. # = significant digits; 0 (zero) = signif. digits or insignif. leading/trailing zeros; '.' = decimal point, ',' = group separator. Note that xslt itself is using en-US culture, adjusting decimal and group separator to local culture has to be specified externally. - Examples: "0.0#" formats 5 / 0.591 as 5.0 / 0.59. "#,###.#" formats 5000 / 0.59 as 5,000 / .6. (Rules for exponential formats or percent may be added in later versions of SDD!)"
|
|
* If you can, adding information how to handle percent in the pattern would be very useful.
|
|
* Move the group: !SpecificExtension to the end (inside Specification)
|
|
* Bob, Jacob: 2. !TaxonHierarchyCoreExtensions/Scope/__TaxonomicScope. If you remove it, you trip over the "no lookahead" validty constraint, because there are two potential things of the same name in the same namespace. Changing the namespace restriction on the extension element seems to violate the convention you use elsewhere.
|
|
* Gregor: Right, this is an error. Please replace the xs:any with the group: !SpecificExtension
|
|
* Bob: 3. !TaxonHierarchyNode/_TypeTaxon and _TypeSpecimens. I assume you are suggesting /neither/ for now, rather than asking for an opinion on which
|
|
* Gregor: Yes, both to be omitted and discussed in the future; the choice is a logic one based on the requirements of the taxonomic codes.
|
|
* Bob: 4. __ReferencePattern and all its associated __'s. Well I admit to being now confused about whether we are in this release omitting all external references as alternative to local references. My understanding is that the conversation yields: yes, for SDD1_1 nothing that has a keyref also supports an external reference.
|
|
* Gregor: YES, sadly version 1.1 will support only document-internal references and no URI-based ones.
|
|
|
|
---
|
|
Bob: These email remarks of Main.DamienBarnier have not been examined yet with respect to b8
|
|
* UBIF_ObjectPattern.xsd has xpath's with unknown u: namespace prefix, need to add xmlns:u=...
|
|
* Gregor: seems already ok in beta 9
|
|
* !SimpleAgentRef extends __AbstractSimpleRef
|
|
* Gregor: fixed.
|
|
* !LabelText and !DetailText have audience references of type !AudienceIdentifier not !LocalInstanceID, is this intentional or was this an omission during the constraint refactoring.
|
|
* Gregor: !AudienceIdentifier removed, now all simply use !LocalInstanceID and type relationship only contained in identity constraints.
|
|
* !AudienceCore extends Audience, which extends !AbstractObjectType. Is there any need for the double extension as the first extension does not add anything to the base type. Similarly !MediaObjectCore extends !MediaObject, which extends !OwnedAbstractObject, again is there a need for the double extension.
|
|
* Gregor: Technically not, but the intention is to have semantic overloading of a base type for each class of the core ontology, and then allow different derivations from this.
|
|
* !OwnerRef has an attribute role with a no type, is this intentional?
|
|
* Gregor: Please check, I cannot follow this. In my files I find: xs:complexType name="OwnerRef" ... xs:complexContent xs:restriction base="RichAgentRef" xs:attribute name="role" type="AgentOwnerRoleEnum" use="required".
|
|
* Encoded_MIME complex type has a naming convention different to all other complex types, ie. an underscore, should this be renamed?
|
|
* Gregor: renamed to !EncodedContent.
|
|
|
|
I did make one additional change, isolating the object identifier from the link collection and move it to a single separate uri-attribute element. Commentators expressed surprise about the placement and concern about it occurring multiple times. Although the latter was by design (alternative url/lsid for same object) it equally possible to chose one as preferred and treat others in links as "Alternative".
|
|
|
|
%META:FILEATTACHMENT{name="SDD1_1b9.zip" attr="h" comment="" date="1146031279" path="SDD1_1b9.zip" size="177760" user="BobMorris" version="1.1"}%
|
|
@
|
|
|
|
|
|
1.11
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 2
|
|
a2 2
|
|
%META:TOPICINFO{author="LeeBelbin" date="1258685125" format="1.1" reprev="1.11" version="1.11"}%
|
|
%META:TOPICPARENT{name="BDI.SDD"}%
|
|
d18 1
|
|
a18 1
|
|
* Gregor: *I propose furthermore to require all id attributes in a document to be unique.* The within-object class (e.g. character) xs:unique should be maintained and should be the source of keyref validation, thus validating both object reference and type-safe class referencing. Background: the decision to only have within-object class identity constraints dates back to a time when BDI.SDD considered id and ref values to be persistent, potentially reflecting database identifiers. However, we have since rejected possible methods to express what kind of identifier is in the id, and decided to rather consider id and ref values as being non-persistent, optionally to be discarded after resolving all references. Under these conditions, it seems more in line with xml-ID usage in other standards (e.g. xhtml) to require document-wide uniqueness. Combining
|
|
d25 1
|
|
a25 1
|
|
* "Format rules as used in the xslt format-number function. # = significant digits; 0 (zero) = signif. digits or insignif. leading/trailing zeros; '.' = decimal point, ',' = group separator. Note that xslt itself is using en-US culture, adjusting decimal and group separator to local culture has to be specified externally. - Examples: "0.0#" formats 5 / 0.591 as 5.0 / 0.59. "#,###.#" formats 5000 / 0.59 as 5,000 / .6. (Rules for exponential formats or percent may be added in later versions of BDI.SDD!)"
|
|
@
|
|
|
|
|
|
1.10
|
|
log
|
|
@Added topic name via script
|
|
@
|
|
text
|
|
@d1 2
|
|
a4 2
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1146575350" format="1.0" version="1.9"}%
|
|
%META:TOPICPARENT{name="WebHome"}%
|
|
d14 1
|
|
a14 1
|
|
* optionality of language and audience attributes
|
|
d16 3
|
|
a18 3
|
|
* I propose to use external validation, both to require uniqueness of labels for different objects, and require within any object to have only a single label for any combination of role, language, audience. -- Main.GregorHagedorn - 27 Apr 2006
|
|
* Jacob & Bob propose (tel.) to change xs:key to xs:unique, and change all xs:keyrefs to refer to these xs:unique instead of xs:key. This seems to be a very good idea to more appropriately reflect the optional nature of the id attribute for local (within-document) references. Gregor.
|
|
* Gregor: *I propose furthermore to require all id attributes in a document to be unique.* The within-object class (e.g. character) xs:unique should be maintained and should be the source of keyref validation, thus validating both object reference and type-safe class referencing. Background: the decision to only have within-object class identity constraints dates back to a time when SDD considered id and ref values to be persistent, potentially reflecting database identifiers. However, we have since rejected possible methods to express what kind of identifier is in the id, and decided to rather consider id and ref values as being non-persistent, optionally to be discarded after resolving all references. Under these conditions, it seems more in line with xml-ID usage in other standards (e.g. xhtml) to require document-wide uniqueness. Combining
|
|
d21 13
|
|
a33 13
|
|
* Bob, Jacob: 1. !UnivariateStatMeasureElaboration/Specification/__FormatPattern vs .../__OrThisInstead. I would go with the !FormatPattern. I think it is strong enough and corresponds to regex support in many programming language libraries. Use it now and see if anyone complains.
|
|
* Gregor: One problem I see is that I do not know how to make this culture specific. XSLT is US-English, so most Europeans (where the US "decimal point" is the comma, and the 1000-separator the period) can not use it for output. But perhaps to make sense to separate formatting structure from culture, and hope that culture is fixed by other means. My proposed changes inside Specification are:
|
|
* Delete the __OrThisInstead
|
|
* Change __FormatPattern to !FormatPattern, change annotation to following:
|
|
* "Format rules as used in the xslt format-number function. # = significant digits; 0 (zero) = signif. digits or insignif. leading/trailing zeros; '.' = decimal point, ',' = group separator. Note that xslt itself is using en-US culture, adjusting decimal and group separator to local culture has to be specified externally. - Examples: "0.0#" formats 5 / 0.591 as 5.0 / 0.59. "#,###.#" formats 5000 / 0.59 as 5,000 / .6. (Rules for exponential formats or percent may be added in later versions of SDD!)"
|
|
* If you can, adding information how to handle percent in the pattern would be very useful.
|
|
* Move the group: !SpecificExtension to the end (inside Specification)
|
|
* Bob, Jacob: 2. !TaxonHierarchyCoreExtensions/Scope/__TaxonomicScope. If you remove it, you trip over the "no lookahead" validty constraint, because there are two potential things of the same name in the same namespace. Changing the namespace restriction on the extension element seems to violate the convention you use elsewhere.
|
|
* Gregor: Right, this is an error. Please replace the xs:any with the group: !SpecificExtension
|
|
* Bob: 3. !TaxonHierarchyNode/_TypeTaxon and _TypeSpecimens. I assume you are suggesting /neither/ for now, rather than asking for an opinion on which
|
|
* Gregor: Yes, both to be omitted and discussed in the future; the choice is a logic one based on the requirements of the taxonomic codes.
|
|
* Bob: 4. __ReferencePattern and all its associated __'s. Well I admit to being now confused about whether we are in this release omitting all external references as alternative to local references. My understanding is that the conversation yields: yes, for SDD1_1 nothing that has a keyref also supports an external reference.
|
|
* Gregor: YES, sadly version 1.1 will support only document-internal references and no URI-based ones.
|
|
d37 12
|
|
a48 12
|
|
* UBIF_ObjectPattern.xsd has xpath's with unknown u: namespace prefix, need to add xmlns:u=...
|
|
* Gregor: seems already ok in beta 9
|
|
* !SimpleAgentRef extends __AbstractSimpleRef
|
|
* Gregor: fixed.
|
|
* !LabelText and !DetailText have audience references of type !AudienceIdentifier not !LocalInstanceID, is this intentional or was this an omission during the constraint refactoring.
|
|
* Gregor: !AudienceIdentifier removed, now all simply use !LocalInstanceID and type relationship only contained in identity constraints.
|
|
* !AudienceCore extends Audience, which extends !AbstractObjectType. Is there any need for the double extension as the first extension does not add anything to the base type. Similarly !MediaObjectCore extends !MediaObject, which extends !OwnedAbstractObject, again is there a need for the double extension.
|
|
* Gregor: Technically not, but the intention is to have semantic overloading of a base type for each class of the core ontology, and then allow different derivations from this.
|
|
* !OwnerRef has an attribute role with a no type, is this intentional?
|
|
* Gregor: Please check, I cannot follow this. In my files I find: xs:complexType name="OwnerRef" ... xs:complexContent xs:restriction base="RichAgentRef" xs:attribute name="role" type="AgentOwnerRoleEnum" use="required".
|
|
* Encoded_MIME complex type has a naming convention different to all other complex types, ie. an underscore, should this be renamed?
|
|
* Gregor: renamed to !EncodedContent.
|
|
@
|
|
|
|
|
|
1.9
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 2
|
|
@
|
|
|
|
|
|
1.8
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1146337516" format="1.0" version="1.8"}%
|
|
d48 1
|
|
a48 1
|
|
I did make one additional change, isolating the object identifier from the link collection and move it to a separate Identity element. Implementations may continue to handle the URIs in a single collection.
|
|
@
|
|
|
|
|
|
1.7
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="BobMorris" date="1146319784" format="1.0" version="1.7"}%
|
|
d33 1
|
|
a33 1
|
|
===
|
|
d35 10
|
|
a44 6
|
|
* UBIF_ObjectPattern.xsd has xpath's with unknown u: namespace prefix, need to add xmlns:u=...
|
|
* SimpleAgentRef extends __AbstractSimpleRef
|
|
* LabelText and DetailText have audience references of type AudienceIdentifier not LocalInstanceID, is this intentional or was this an omission during the contraint refactoring.
|
|
* AudienceCore extends Audience, which extends AbstractObjectType. Is there any need for the double extension as the first extension does not add anything to the base type.
|
|
* MediaObjectCore extends MediaObject, which extends OwnedAbstractObject, again is there a need for the double extension.
|
|
* OwnerRef has an attribute role with a no type, is this intentional?
|
|
d46 3
|
|
@
|
|
|
|
|
|
1.6
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1146214889" format="1.0" version="1.6"}%
|
|
d33 10
|
|
@
|
|
|
|
|
|
1.5
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1146210212" format="1.0" version="1.5"}%
|
|
d19 1
|
|
a19 1
|
|
* Bob, Jacob: 1. UnivariateStatMeasureElaboration/Specification/__FormatPattern vs .../__OrThisInstead. I would go with the FormatPattern. I think it is strong enough and corresponds to regex support in many programming language libraries. Use it now and see if anyone complains.
|
|
d22 2
|
|
a23 3
|
|
* Change __FormatPattern to FormatPattern, change annotation to following:
|
|
* "Format rules as used in the xslt format-number function. # = significant digits; 0 (zero) = signif. digits or insignif. leading/trailing zeros; '.' = decimal point, ',' = group separator. Note that xslt itself is using en-US culture, adjusting decimal and group separator to local culture has to be specified externally. - Examples: "0.0#" formats 5 / 0.591 as 5.0 / 0.59. "#,###.#" formats 5000 / 0.59 as 5,000 / .6. (Rules for exponential formats or percent may be added in later versions of
|
|
SDD!)"
|
|
d25 4
|
|
a28 4
|
|
* Move the group: SpecificExtension to the end (inside Specification)
|
|
* Bob, Jacob: 2. TaxonHierarchyCoreExtensions/Scope/__TaxonomicScope. If you remove it, you trip over the "no lookahead" validty constraint, because there are two potential things of the same name in the same namespace. Changing the namespace restriction on the extension element seems to violate the convention you use elsewhere.
|
|
* Gregor: Right, this is an error. Please replace the xs:any with the group: SpecificExtension
|
|
* Bob: 3. TaxonHierarchyNode/_TypeTaxon and _TypeSpecimens. I assume you are suggesting /neither/ for now, rather than asking for an opinion on which
|
|
@
|
|
|
|
|
|
1.4
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1146131379" format="1.0" version="1.4"}%
|
|
d10 2
|
|
d15 18
|
|
a32 1
|
|
|
|
@
|
|
|
|
|
|
1.3
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="BobMorris" date="1146103298" format="1.0" version="1.3"}%
|
|
d11 2
|
|
a12 3
|
|
The cost of this is seen in this scenario: Consider an instance document with, say 300 state labels all 'blue' together with one state 'red' on a character "flower color". An application whose UI is automatically generated from the state list (as all conceivable applications will do), and which does not check the (several combinations of) possible non-uniqueness, will offer 300 choices of 'blue' and one of 'red'. I note, however, that a robust application would probably tolerate this _even_ if it were signalled by a schema validator, unless the application writer chose some kind of normalization strategy that would rewrite a semantically equivalent but valid document, e.g. in this case removing duplicates.
|
|
|
|
-- Main.BobMorris - 26 Apr 2006
|
|
@
|
|
|
|
|
|
1.2
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="BobMorris" date="1146031460" format="1.0" version="1.2"}%
|
|
d3 1
|
|
a3 1
|
|
* *[[%ATTACHURL%/SDD1_1b9.zip][SDD1_1b9.zip]]*
|
|
d5 1
|
|
a5 1
|
|
SDD1_1b9 has these changes from b8
|
|
a6 3
|
|
1 Provide for CVS Ids as comments in every file. I will publish how we are archiving at SddCvs.
|
|
1 Remove almost all "__" elements and types. These are the "for future discussion" objects. SDD1_1b8 is therefore the designated version containing those. Care must be exercised in putting them back into derivatives of b9. A few more have to be dealt with for b9 and remain therein. These will be removed in b10. A list of those removed already is in the file diffs.xml in [[%ATTACHURL%/SDD1_1b9.zip][SDD1_1b9.zip]] .
|
|
1 !TaxonHierarchy/TaxonHierarchyType moved to !TaxonHierarchy/Specification/TaxonHierarchyType
|
|
d8 1
|
|
a8 1
|
|
Main.JacobAsiedu will fix uniqueness constraints from b9 to form the base of b10.
|
|
d10 2
|
|
a11 3
|
|
b9 should be ignored by all but Gregor, Bob and Jacob.
|
|
|
|
I propose that Kevin begin documenting from b10 when it is released and the release SDD1_1 be whatever results from such small points or disaster fixes that are discovered in b10.
|
|
@
|
|
|
|
|
|
1.1
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="BobMorris" date="1146027478" format="1.0" version="1.1"}%
|
|
d3 2
|
|
d7 3
|
|
a9 1
|
|
1. Provide for CVS Ids as comments in every file. I will publish how we are archiving at SddCvs.
|
|
d11 1
|
|
a11 1
|
|
1. Remove almost all "__" elements and types. These are the "for future discussion" objects. SDD1_1b8 is therefore the designated version containing those. Care must be exercised in putting them back into derivatives of b9. A few more have to be dealt with for b9 and remain therein. These will be removed in b10.
|
|
d13 1
|
|
a13 1
|
|
1. !TaxonHierarchy/TaxonHierarchyType moved to !TaxonHierarchy/Specification/TaxonHierarchyType
|
|
d15 1
|
|
a15 1
|
|
Main.JacobAsiedu will fix uniqueness constraints from b9 to form the base of b10.
|
|
d18 1
|
|
d20 1
|
|
@
|