1. Voucher is a role-based name. The name is excellent for a ref, which would be role-specific, but to keep things as general as possible it would be good to use a more general name (Specimen, or following ABCD, Unit).

Yes we have been thinking along these lines. Specimen is too narrow because in the absence of specimen GUIDS we need to have repository information as part of the 'Voucher'. We would like ultimately to use the ABCD representation, but again this is not easy as the Unit also requires Source institution details etc. TrevorPaterson 12 Aug

2. Looking through the schema, it is difficult to find the place where Voucher is referenced. The name Voucher is not used elsewhere. Reading the keyrefs, I could figure out that it is referred to by TaxonConcept/SpecimenCircumscription/CircumscribedBy. If it does not complicate, I believe it would be better to use SpecimenCircumscription/Voucher/@ref=.

We changed from using Voucher as some reviewers thought that it was better not to use the same name for a reference to an object. An alternative might be VoucherRef etc. TrevorPaterson 12 Aug

I would favour ByVoucher (preposition & target element) as also used for by example ToTaxonConcept FromTaxonConcept. --RobertKukla 12/8/04

I personally think using the same element name (with attributes id and ref, respectively) is the most common pattern. It is used in xhtml (a element with name/id and href), xml schema (group/element/attribute with name and ref, respectively), and maps most closely to usage in object modelling. A variable containing a pointer to a class is by default named with the class name, and different only if indeed different role/preposition are possible. -- GregorHagedorn, 13. August 2004

This is what we had in the StrawMan (And what I prefer) but it was disliked (I think mainly it was confusing to talk about - the element name alone was not a unique identifier). With elements that have two (or more) subelements of the same type you get an additional problem: how to destinguish between them? (e.g. relationship from, to). I suppose it could be done via an attribute. --RobertKukla 16/08/04

3. The Voucher has an id attribute, the Specimen an identifier annotated as being a local identifier. The local identifier is required, so I assume in any case where a collection is not yet digitized it will be string like "Colletotrichum from Strawberry, 21.6.1999, G. Hagedorn leg."?

It could be any string as used by that repository to identify the specimen. TrevorPaterson 12 Aug

Agreed. Since it is impossible what kind of organisation/classification is used we intend this to be used as a free text field. --RobertKukla 12/08/04

Without contradicting, just the explanation is wrong. Traditionally most repositories have not given identifiers to specimens, so each researchers uses parts of the label information (for which some vague conventions exist in different fields), which she or he believes to make the specimens identifiable. -- GregorHagedorn, 13. August 2004

4. Voucher/@id is typed NCName which conflicts with the annotation that this may be a GUID. www.xyz.com is valid, but "http://www.xyz.com", "297432", or "urn:lsid:www.xyz.com:297432" are not.

5. NCName is used in other places as well (e.g. Assertion), and prevents the use of plain integers.

I think that NCNames are Names that can't begin with colons... but can begin with a letter or an underscore so we need to change this to allow integers. TrevorPaterson 12 Aug

Historically this stems from the time when ID/ID-REF was used for integrity constraints. If NCNames is deemed to be too restrictive, it can be loosened - to token perhaps? --RobertKukla 12/8/04

6. I don't understand Repository. It contains empty elements InstitutionName, Code with no attributes or content. I guess the content (xs:string?) has been forgotten?

Its not necessary to specify simple text content for an element is it? TrevorPaterson 12 Aug

While not necessary, it will be useful to restrict it to type. It might be more important to find out though if people find these bits of information sufficient. --RobertKukla 12/8/04

To my knowledge it is necessary, please correct me if I am wrong. I think you explicitly define in your schema that the element MUST be empty. -- GregorHagedorn, 13. August 2004

If no type is specified for an element it allows for any string contents. If you want an element to be empty you have to define a complex type for it that doesn't have anything in it. --RobertKukla 13/08/04

Gregor Hagedorn -- 12. August 2004