[tcs-lc] Modularisation of standards

[Bob Morris]

Richard Pyle wrote:
>>>The version I've been mulling about in my mind would look like this:
> 
> 
> [...]
> 
> 
>>I have no problems with this. However, the example makes probably
>>an implicit
>>assumption that content (which elements occur inside
>>TaxonConcept) can depend
>>on the value of the Type attribute. This is not supported in xml schema.
> 
> 
> Right -- the approach I'm taking appears to involve some faith on the part
> of the data providers to conform to business rules that are probably not
> easily enforced within the schema itself. I don't know what the practical
> "cost" of that would be, compared with the "cost" of treating names as
> top-level objects, or the "cost" of not modularizing names data.  Bob Morris
> would be the one to comment here -- he spend a bit of time trying to show me
> how to deal with these sorts of restrictions in an XML schema, but a lot of
> his explanations were over my head.  Bob -- perhaps you can elaborate in the
> context of the specific imlementation we discussed?
> 
I've put the relevant topic and files on the wiki at 
http://bdei.cs.umb.edu/twiki/bin/view/UBIF/LinneanCoreMultipleStructuresForNames

The first paragraph there is non-technical and says:

In discussion on the mailing list, RichardPyle expressed the desire that 
the Name element in a Taxon Concept that has type="Nominal" have an 
enforceably (sensu XML Schema Validation) distinguishable structure from 
all other types. GregorHagedorn pointed out that this is not directly 
possible in XML, but it is possible if one is willing to permit the 
distinctions to be expressed with different element names, e.g. 
NominalTaxonConcept, NominalName, NonNominalTaxonConcept, 
NonNominalName, (not the names we used) or some other such distinction 
as would satisfy the community. In this case, the datatype inheritance 
mechanisms of XML Schema can solve the problem technically, leaving only 
the social question of whether this element name proliferation is 
acceptable or not. For that point, the arguments probably come down to 
which side of the "humans don't matter" debate you are on. If, as I, you 
believe that Schema readability is secondary, especially to other than 
Schema specialists, then probably it doesn't matter whether you have two 
names where you could have one if you are content (as I am not) to let 
annotations urge compliance, rather than have validating parsers detect 
non-compliance. As a secondary argument, note that schema compilers like 
Castor can not generate XML marshalling/unmarshalling source code that 
enforces dreams in the annotation, but certainly can do so for code 
where distinctions are enforced by the schema.

> 
>>As the example shows, records of type="Nominal" would have
>>different content
>>than those of other types, which can not be validated in w3c xml
>>schema. This
>>is a known limitation.
> 
> 
> I didn't represent it very well -- I was following Donald's lead on the name
> elements.  I think I can conform the set of elements in my notion of a
> Nominal Concept to be much more similar to the element structure in other
> concept types (will work on this tonight).
> 
> 
>>Note that it is possible to rename
>>
>>   <TaxonConcept id="tc0" type="Nominal">
>>to
>>   <NominalConcept id="tc0">
>>
>>and still have a single collection, if this should be socially
>>desirable. A
>>collection of elements may be a repeated choice, yielding any
>>sequence such as:
>>
>>TaxonConcept
>>NominalConcept
>>NominalConcept
>>TaxonConcept
>>NominalConcept
>>TaxonConcept
> 
> 
> Whichever is the more palatable approach -- I have not studied XML design
> long enough to have an opinion.  However, if going this route, I would
> propose something more like:
> 
> <Taxa>
>   <TaxonConcept/>
>   <TaxonName/>
>   <TaxonConcept/>
>   <TaxonConcept/>
>   <TaxonName/>
>   <TaxonConcept/>
> </Taxa>
> 
> But there are other aspects of that I do not like.  Let me try to represent
> it in a schema representation, and in an instance document.
> 
> Rich
> 
> 
> _______________________________________________
> tcs-lc mailing list
> tcs-lc at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/tcs-lc

-- 
Robert A. Morris
Professor of Computer Science
UMASS-Boston
http://www.cs.umb.edu/~ram
phone (+1)617 287 6466