Re: Pycoon?

On Nov 16, 2003, at 5:59 PM, Bruce D'Arcus wrote:

>
> On Nov 15, 2003, at 12:55 PM, Kimbro Staken wrote:
>
>> There is also nothing that prevents using a constraining schema  
>> language around the edges. For instance you can certainly validate  
>> the document before you put it in Syncato. Of course it will probably  
>> never validate again because syncato will stick an id attribute in  
>> the root node and a pubDate element as a child of the root. So if you  
>> really want  a system that will enforce the schema Syncato won't be  
>> it.
>
> Oh, on this:
>
> I take it this is flexible, though?

Flexible in what way? Right now it always adds them to any document  
that is inserted. They really should be in a namespace, but they're  
not. That will come at some point though. But even that won't matter as  
the document still won't validate with those extra nodes in it. Those  
nodes are required by the system to function, but when a document  
leaves the system you can always strip them out.

My feeling on standard schemas is that you should store whatever you  
want inside Syncato and just ignore the schema. Then when you need the  
data to leave the system put it in whatever Official format is required  
and run that through a validator. Obviously to do that you have to have  
all the required bits to create the standard doc, how you get that is  
up to you.


> For example, the metadata schema I am interested in allows for these  
> data to be coded; there's an ID attribute on the root node (as well as  
> on others as well), and there are a variety of ways to code dates.   
> However, I would likely already have the ID value coded.*

Actually your ID won't conflict with the syncato id simply because they  
use different case.

>
> Also, one of the ideas I was kicking around was to separate out the  
> metadata records (which must conform to this schema) from the notes  
> that may be linked to them (where structure/validity is really only  
> important to the degree I can run consistent queries and  
> transformations on the data).
>
> Bruce
>
> * Typically when dealing with bib data one wants an easily remembered  
> citation key; something like Smith1999a.  So, at least currently, I am  
> attaching this value to the ID attribute.  The schema I am interested  
> in also would allow me to code the same data like so and leave the  
> root ID attribute uncoded:
>
> <identifier type="citekey">Smith1999a</identifier>
>
> Bruce
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/ 
> g22lp.tmpl
> _______________________________________________
> Syncato-general mailing list
> Syncato-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/syncato-general
>
>
Kimbro Staken
Software, Consulting and Writing http://www.xmldatabases.org/
Apache Xindice native XML database http://xml.apache.org/xindice
XML:DB Initiative http://www.xmldb.org



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl