Very true. After reading the UNCW document more closely, I realised that
adding or changing one metadatafield would mean modifying your tables, which
is never a nice thing to do. In the case of UNCW, it would mean changing a
lot of other things, like GUI-fields, also.

The abstract method you describe is more flexible, but potentially much
slower, more complex to code etc.
If the interface parts, where you edit/add the metadatafield, aren't as
flexible as the databasedesign, a change in the metadataschema would still
mean codechanges in your application.

The Dr.Tom article suggests to consider the question you raised: do you
really want ALL the fields for your search?
If you only search for ID, Title and a couple of other fields, then you
could just store those in the database and use it to build your queries. You
can then store the complete manifest either as a BLOB or on file (referenced
from within the database) and return that if needed so all the other
metadata still is available.
That way you would have an easy to maintain, easy to build an fast working
setup, which also leaves the option to import the original manifest files
with all the metadata into a new system that you might build/buy some time
from now.

So yes, I think your remarks make much sence.

Pierre

----- Original Message -----
From: "Scott Wilson" <[log in to unmask]>
Sent: Thursday, February 20, 2003 2:42 AM
Subject: Re: XML to Database (NLN)


> All,
>
> I think everyone who tries building a like-for-like relational schema to
map
> the XML schema regrets it. Its an obvious first thing to do, but can cause
> tremendous difficulties, especially when schemas are changed, or you need
to
> support several specification versions. It _will_work_. But only for
version
> 1.0 of your solution!
>
> One approach some vendors have taken is to do an more abstract map of
> simpler tables (IMSElement, IMSAttribute etc.) and use that to build
> persistence. Seek times are longer than with a concrete map, but at least
> you can represent a wider variety of cases without getting referential
> integrity errors and the like.
>
> My colleague Phil Beauvoir is in the middle of creating an application
> framework for working with all of the IMS-type specifications, which may
> offer a solution in the longer term (e.g, working with Java objects and
then
> using something like Bean Managed Persistence to deal with the nitty
gritty
> of data handling).
>
> A library I wrote for the Python language does pretty much the same sort
of
> thing on the Zope platform but just for Content Packaging and a bit of
> Metadata; Phil's Java library is shaping up to be far more powerful,
> especially for building different types of editing tools.
>
> If you are using SQL Server, I might suggest writing some COM objects to
> handle the logic...and using DTS packages to handle the import process.
IF,
> that is, you are actually wanting to access the whole package
functionality
> out of SQL!
>
> Other approaches include saving the whole imsmanifest.xml as a BLOB and
then
> loading it into a DOM parser for interpreting. If you are using SQL Server
> then you can always write a bunch of COM classes to abstract the XML and
> reference the DOM, and do a user interface with ASP.
>
> However, as I write I get the feeling I'm moving further and further away
> from the solution you may actually need for your situation! Perhaps some
> more requirements may suggest something a bit quicker to actually
implement?
>
> For example, if you're just going to provide a listing of titles and
> downloadables for people to click on then you needn't do any of this
stuff -
> just read in the titles and store the packages as BLOBs or in the file
> system!
>
> Hope this is of interest...
>
> - Scott
>
> On 19/2/03 10:54 pm, "Pierre Gorissen" <[log in to unmask]> wrote:
>
> > Hi Paul,
> >
> > No personal experience trying to do this myself, but I did some
searching
> > and found at least one group of people that did try and succeeded. See:
> > http://aa.uncwil.edu/dl/documents/designing%20the%20ims%20database3.doc
> > Some wise words from Dr. Tom on the subject:
> > http://www.imsglobal.org/drtomimplement.cfm
> > More generic info about XML and relational databases:
> > http://www.rpbourret.com/xml/XMLAndDatabases.htm
> >
> > The info should at least get you past the creation of the tables,
> relations
> > etc. (I hope).
> >
> > Kind regards,
> >
> > Pierre Gorissen
> > IT Consultant
> >
> > Fontys University of Professional Education
> > Educational Development Department
> > P.O. Box 347
> > NL-5600 AH Eindhoven
> > The Netherlands
> >
> > Phone: +31-(0)877 879 369
> > Fax: +31-(0)877 875 822
> > Mail: [log in to unmask]
> > Web: http://www.fontys.nl/
> >
> > ----- Original Message -----
> > From: "Paul Kennedy" <[log in to unmask]>
> > Sent: Tuesday, February 18, 2003 5:51 PM
> > Subject: XML to Database (NLN)
> >
> >
> >> Hi there,
> >>
> >> I'm quite new to IMS, XML, metadata, etc. Phil Barker picked up my
query
> > on
> >> another list and suggested I post here.
> >>
> >> I'm trying to setup and index the NLN materials on our college intranet
/
> >> VLE. I need to know if and how I can convert the manifest.xml (metadata
> >> tags) into a database schema for use in Access or MSSQL. It seems
> sensible
> >> to use the info in the manifest files but I'm a bit lost as to how I
can
> > do
> >> this. I tried using Filemaker Pro 6 but was hitting an error when I
tried
> >> to import the .xml file.
> >>
> >> Any help or ideas will be much appreciated.
> >>
> >> Paul Kennedy
> >> Web Development Officer
> >> Belfast Institute of Further and higher Education
> >>
>
>