Re: Generic Embeddable plugins.

On 12 Jan 2005, at 12:16, Jean Bréfort wrote:
>>> For XML data, the appropriate plugin might be determined using XML
>>> namespaces.
>>
>> Technically all namespaces in a document should be defined in the DTD
>> (not that Abi's DTD is anywhere near up-to-date).
>
> Why? I do not understand that. XML namespaces have been devised to give
> the possibility to make modular documents with data coming from
> multiple
> software modules. You don't need everything described in the main
> document DTD os schema.

I'd be happy to be proved wrong, but my experimentation with XML
namespaces and DTDs a couple of years ago suggested otherwise. Perhaps
XML Schema are more flexible. Anyway, it's largely irrelevant.

>> My real objection is that it's Abi that would be responsible for
>> parsing & creating the embedded XML, which although possible is
>> technically awkward.
>
> The plugin should do that, not abiword. I do not think it is so
> difficult.

It's certainly doable, but it does make the plugin's job harder.

And then, also, AbiWord has to trust that the plugin is exporting valid
XML.

>> Far better, imho, to store all generic embedded data as base-64
>> encoded
>> data along with the name of the responsible plugin, a mime-type, and a
>> base-64 encoded image preview.

My concern here is that while it is possible to embed XML data such as
SVG and MathML as XML in the AbiWord document, if (for example) you
create an SVG image in Adobe Illustrator, insert it into AbiWord, later
extract it from AbiWord, then the resulting SVG will not be the
original. Now, you may argue that the differences are acceptable, but
it doesn't really satisfy me. The easiest way around this is to embed
the original file (base-64-encoded, naturally).

Such fun,
Frank
Received on Wed Jan 12 21:38:03 2005