[alicebot-archcomm] [discussion] extension mechanism

[Noel Bush]

On Wed, 2002-05-22 at 15:58, Manos Batsis wrote:
> I'd prefer #1 <extension> instead of introducing a new custom element
> per extension. It helps XML validation and semantic awareness. A new
> extension element type per extension would be a nightmare!
> If we stick to interpreted languages such as python, JavaScript etc, the
> code can be embedded in the document using an extensionImplementation
> (or whatever) element to be globally accessible:
> 
> <extensionImplementation type="text/javascript"
> processor="myJSProcessor.exe" id="foo">
[snip]
> I've specified the MIME type and local processor. How about remote
> services/processors?

I like the idea of using MIME types, although my next question is what
to do in the case that the content isn't covered by a MIME type.

I still think that a URI should be used for specifying the processor,
rather than some path to a local processor as you illustrated --
naturally the program can be built to have local knowledge of which
processor to use for the URI (without needing to look it up).  This is
all in the interest of portability.

> Anyway, by using standard element names for introducing and using
> extensions, you will always know that this is an extension; validation
> is easy since you just introduce a complex type to the XML Schema.
> Introduction of new namespaces is, IMHO, a complexity we can live
> without.

I agree with this point.  I am inclined to trust Manos's intuition on
this point, too, due to his experience.

> > > > I would characterize the extension mechanism as a 
> > generalization of the
> > > > <system> and <javascript> functions currently available.  The
> > > > requirements I would like to propose are:
> > > >
> > > > 1. Unrestricted text content, within the guidelines given 
> > for XML, for
> > > > extension elements.
> > > > -- Meaning, any kind of CDATA is acceptable (although in 
> > cases where
> > > > characters need to be "escaped" to avoid conflicts with 
> > XML they should
> > > > be).
> 
> Agreed. How about refering to external files?

Right -- so we need an href attribute.