W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2004

Re: L3 LS: Configuration parameter to enable/disable application specific DOM

From: Curt Arnold <carnold@houston.rr.com>
Date: Sun, 04 Jan 2004 15:47:07 -0600
Message-ID: <3FF889DB.1000607@houston.rr.com>
To: www-dom@w3.org

Not hindered by any knowledge of either CORE-3 or domain specific DOMs (so

>not sure on 'thought this through' part), let me try to add something to the
>discussion. Is this problem not taken care of by DOMImplementationSource of
>CORE-3? There you can get a DOMImplementation supporting features you want
>(e.g. SVG?). And that DOMImplementation you cast to DOMImplementationLS, and
>get a parser on. So if you were a DOM implementor and wanted to distuinguish
>between regular DOM building and e.g. SVG DOM Building you could control it
>in your DOMImplementationSource impl?
>(And if you do LS but not CORE3, then you can add your own impl specific
>params on LSParser as you suggest)
>Kind regards,
You could consider, for example, Xerces configured to build an XHTML DOM 
as a distinct implementation from Xerces configured to build a generic 
DOM.  However, there is not a way to negate a feature on 
getImplementation(), that is to say I want an implementation that 
implements Core but want to disable creation of SVG specific element 
implementations, so you would have to rely on the generic 
"implementation" appearing in the list before the application aware 
"implementation" if you wanted to disable application specific behavior.

I'm still thinking that this is more of a configuration level item than 
an implementation level item.  It could also affect the element 
implementation chosen by createElementNS and other DOM creation 
methods.  However instead of specifying features to support, may be it 
would be better to have a boolean configuration parameter that could be 
used to suppress application-aware behavior.

Maybe something like the following added to the list of configuration 
parameters in Core:

[required] (default)
The implementation may enforce implicit application-specific 
constraints.  For example, an SVG-aware application may throw an 
VALIDATION_ERR DOMException on an attempt to create an element in the 
SVG namespace with an unrecognized local name or may fail to load an SVG 
document that is inconsistent with the SVG specification.

false [optional]
The implementation must not enforce any implicit application-specific 
constraints.  Setting this parameter to false may disable 
application-specific DOM extensions.
Received on Sunday, 4 January 2004 16:47:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:12 UTC