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

[Alistair Y. <ali...@sm...>]

> The simplest is to strip the namespace information during import, as
> nature appears to have intended things...
> ...not possible to
> reconstruct anything useful.
well that option's out then

> The next simplest is to store the namespace URI with each row in
> xml_elements and xml_attributes
sounds the easiest, simplest and most reliable - do we care about disk=20=

space? how many nanopence is it now per Gb?

> Next harder is trying to store a mapping of namespace prefixes to
> namespace URIs...
> ...not guaranteed to work with all SAX2 parsers
well that option's out then too!

> Hardest is ripping out the existing XML repository and replacing it=20
> with
> an off-the-shelf XML database - I'd probably use eXist,
eXist has been talked about here too, in connection with other=20
projects. Perhaps this is the way for tetra? I question whether large=20
sums of cash are worth pouring into bod if tetra is on the way.

from the above list, I'd vote for number 2.

Alistair


On 25 May 2005, at 15:24, Peter Crowther wrote:

> At present, the XML repository has no notion of namespace URIs or
> namespace prefixes.  This give rise to some rather entertaining=20
> 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=20
> package
> import fails as the code can't find <record> under the <metadata> tag.
>
> There are a number of ways around this.  I'm looking for input on =
which
> of these might be appropriate for other developments.
>
> 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.
>
> 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=20
> space.
>
> 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=20
> manufactured.
> It's also not guaranteed to work with all SAX2 parsers, as returning=20=

> the
> namespace prefix is an optional facility.  However, it reduces the =
disk
> space considerably.
>
> Hardest is ripping out the existing XML repository and replacing it=20
> 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. =20=

> 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!
>
> Does anyone have any preferences, before I shrug and go for the =
easiest
> approach that serves my needs for now?
>
> 		- Peter
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: GoToMeeting - the easiest way to=20
> collaborate
> online with coworkers and clients while avoiding the high cost of=20
> travel and
> communications. There is no equipment to buy and you can meet as often=20=

> as
> you want. Try it=20
> free.http://ads.osdn.com/?ad_idt02&alloc_id=16135&op=3Dclick
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers