RE: [Bodington-developers] XML Repository and namespace prefixes

[Adam M. <ada...@co...>]

--
Adam Marshall:       OUCS, 13, Banbury Rd. Oxford OX2 6NN.
Shameless plug:      Use the Bodington VLE http://bodington.org
Blog:                http://ramble.oucs.ox.ac.uk/blog/adamm/
Cheese of the month: Cheshire (not to be underestimated)=20

| -----Original Message-----
| From: bod...@li... =
[mailto:bodington-
| dev...@li...] On Behalf Of Peter Crowther
| Sent: 25 May 2005 15:24
| To: bod...@li...
| Subject: [Bodington-developers] XML Repository and namespace prefixes
|=20
| At present, the XML repository has no notion of namespace URIs or
| namespace prefixes.  This give rise to some rather entertaining =
problems
| with more recent IMS content packages (basically anything 1.1 and
| above).  For example, the <record> element of Aggie's 1.1.2 content
| package is stored as <imsmd:record> - which means that a content =
package
| import fails as the code can't find <record> under the <metadata> tag.
|=20

Thumb goes down.

| There are a number of ways around this.  I'm looking for input on =
which
| of these might be appropriate for other developments.
|=20
| The simplest is to strip the namespace information during import, as
| nature appears to have intended things.  This works fine... until the
| time comes to reconstruct the XML for output, at which point the
| information loss may well be sufficient that it is not possible to
| reconstruct anything useful.
|=20
| The next simplest is to store the namespace URI with each row in
| xml_elements and xml_attributes.  Cheap'n'cheerful, full-fidelity
| reconstruction, works with any SAX2 parser, but expensive on disk =
space.

Thumb goes up. Surely a namespaces table:

        String | integer

With the addition of a single int column the each xml element and attr =
row
wouldn't be too bad??

|=20
| Next harder is trying to store a mapping of namespace prefixes to
| namespace URIs, and store the prefixes with each element and =
attribute.
| It's harder because there's always the possibility of getting =
something
| without namespace prefixes, at which point they need to be =
manufactured.
| It's also not guaranteed to work with all SAX2 parsers, as returning =
the
| namespace prefix is an optional facility.  However, it reduces the =
disk
| space considerably.
|=20

Is this necessary - do we need to actually store the namespace prefix in
Bod? Couldnt we just make up something from the URI? Ugly but works
perfectly? After all who's going to be hand editing our exported XML?

| Hardest is ripping out the existing XML repository and replacing it =
with
| an off-the-shelf XML database - I'd probably use eXist, as I have some
| experience with it and it would work for this job.  This adds the
| complexity of another component and another data store (eXist uses its
| own .dbx files), but removes one more bespoke piece from Bodington.  =
I'm
| not going to be able to do this within the timeframe of the existing
| project unless someone comes up with some more dosh!

Surely when we move to VFS in X years time this will be taken care of?

|=20
| Does anyone have any preferences, before I shrug and go for the =
easiest
| approach that serves my needs for now?
|=20
| 		- Peter
|=20
|=20
| -------------------------------------------------------
| SF.Net email is sponsored by: GoToMeeting - the easiest way to =
collaborate
| online with coworkers and clients while avoiding the high cost of =
travel
| and
| communications. There is no equipment to buy and you can meet as often =
as
| you want. Try it =
free.http://ads.osdn.com/?ad_idt02&alloc_id=16135&op=3Dick
| _______________________________________________
| Bodington-developers mailing list
| Bod...@li...
| https://lists.sourceforge.net/lists/listinfo/bodington-developers