"Tony Proctor" <tony_proctor@aimtechnology_NoMoreSPAM_.com> wrote in news:fdifec$v25$1@reader01.news.esat.net: > I was thinking of "interoperability" though Ian. I agree with the > principles of first defining an abstract data model, and then ensuring > there's an exchange format that can be used for import/export, email, > etc. However, if each proprietary database provides an implementation > standard API then it means other software can examine (& optionally > update) data still in that proprietary database, without the need for > convoluted import/export. > To some extent XML also specifys interoperability, if you consider that to read it you need to be able to do something with the data (at least read and hopefully show it in the context of the schema), and should be able to write it back someplace in the context of the schema you got it in. Most of the comments I see about XML being inappropriate deal with either the labels or usage logic or the granularity of the schema. Everyone overlooks the "extensible" benefit of strict XML and the data itself in context with a known scheme. > A software designer with a great idea, for instance, could write their > utility conforming to the description of that API. Anyone could then > use it if the supplier of their current database offers an > implementation of that API. > > Tony Proctor > > "Ian Goddard" <goddai01@hotmail.co.uk> wrote in message > news:78idneS-vee9p2HbnZ2dnUVZ8sylnZ2d@pipex.net... >> Tony Proctor wrote: >> > My case is for a standardised database representation Jack. There >> > mere > fact >> > a program is using SQL doesn't mean another program can come along >> > and > use >> > the same data. I suggested a standardised 'SQL schema' but I'm not >> > sure > what >> > bodies would have to be involved in defining and ratifying such a > schema. >> > >> > Such a schema would not compromise the flair and ingenuity of >> > existing programs, but it would "open up the field" by separating >> > the data from > the >> > programs >> > >> > GEDCOM/XML would then be purely interchange formats, which is >> > probably > what >> > they're best at anyway. >> > >> > Tony Proctor >> > >> >> I think that what needs to be got right in the first place is the >> data model. >> >> From that you would head off along two development paths. One would >> be >> implementation within an application and the other would be data >> exchange. >> >> For implementation purposes the developers could choose their own >> internal representation. They could use non-SQL RDBMS, SQL, XML, >> object-relational, persistent objects or even punched cards (that >> dates me!) if it did the job for them. >> >> For data exchange XML is pretty well a no-brainer so the second >> standardisation step would be to define an XML schema. Given that >> one would have some degree of control over standards conformance of >> applications. For instance a conformant program would have to be >> able to import any valid XML document (for non-XMLers a "document" is >> what you would probably call a file, a "valid" document is one which >> is in accord with the schema) and any exported document would have to >> be valid and it should be able to import a document and, in the >> absence of any editing by the user, export a functionally equivalent >> document. > >