[tcs-lc] Order of elements in TCS schema

[Roger Hyam]

The order of publications, vouchers, names, taxon concepts is a bit of a 
red herring as most non trivial programs will probably have to do some 
'object juggling' of some kind anyhow. If, for example, you are  
producing *only* TaxonConcept objects there are a vast number of 
permutations of relationships between even only a few objects (congruent 
to, parent of, child of etc). The script producing the document will 
have to either construct a query very carefully or keep track of all the 
other TCs that are referenced and whether or not they have been written 
to the stream.

What I think will happen in most cases is that only 'fancy' (labelled) 
pointers will be written in response to a query and thus the referencing 
problem will go away in a great many cases and construction of the 
schema will be quite simple.



Bob Morris wrote:

>This seems to me to be a matter of who gets to use SAX instead of DOM 
>API, producer or consumer. With a small amount of work you can probably 
>make an xslt program that will make a depth-first tree into a 
>bread-first tree or vice-versa, but it hardly seems worth the effort 
>since I suppose the relevant trees are probably usually small enough to 
>fit in memory and be traversed on the fly. We remain a big fan of 
>Castor, which will produce all the marshalling and unmarshalling code 
>for you and leave very little but the tree traversal code to write.
>
>--Bob
>
>
>Sally Hinchcliffe wrote:
>
>  
>
>>Hi Robert
>>You wrote:
>> 
>>
>>    
>>
>>>You wrote:
>>>   
>>>
>>>      
>>>
>>>>Is there a reason why, somewhere between v085 and 095, the 
>>>>publications got put ahead of the concepts?
>>>>     
>>>>
>>>>        
>>>>
>>>It was a request from the SEEK team. They didn't want any forward
>>>references in the XML. So I guess one party (producer or consumer) is
>>>always at a disadvantage. But since relationships between concepts can
>>>still go in arbitary directions, it might me desirable to generate the
>>>complete XML document (or a binary equivalent) in memory first and write
>>>it at the end of the generation.
>>>
>>>   
>>>
>>>      
>>>
>>I think this is how it's going to have to be ... as the customer is 
>>always right!
>>Thanks
>>Sally
>>*** Sally Hinchcliffe
>>*** Computer section, Royal Botanic Gardens, Kew
>>*** tel: +44 (0)20 8332 5708
>>*** S.Hinchcliffe at rbgkew.org.uk
>>
>>_______________________________________________
>>Tcs-lc mailing list
>>Tcs-lc at ecoinformatics.org
>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/tcs-lc
>> 
>>
>>    
>>
>_______________________________________________
>Tcs-lc mailing list
>Tcs-lc at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/tcs-lc
>
>  
>

-- 

==============================================
 Roger Hyam
----------------------------------------------
 Biodiversity Informatics
 Independent Web Development 
----------------------------------------------
 http://www.hyam.net  roger at hyam.net
----------------------------------------------
 2 Janefield Rise, Lauder, TD2 6SP, UK.
 T: +44 (0)1578 722782 M: +44 (0)7890 341847
==============================================


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050415/08fbea37/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: roger.vcf
Type: text/x-vcard
Size: 275 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/tcs-lc/attachments/20050415/08fbea37/roger.vcf