[
Lists Home |
Date Index |
Thread Index
]
3/6/2002 1:28:03 PM, "Bullard, Claude L (Len)" <clbullar@ingr.com>
wrote:
>A theoretical question. Given an XML aggregate
>document such as HTML inside SVG inside X3D,
>what should one expect the API to do? XML
>DOM is generic. HTML DOM and SVG DOM add
>their own API extensions. An author learns
>one or all in their separate browser objects.
>Then one sunny day, they use namespaces and
>aggregate these. Do they get to leverage
>what they have learned? How?
DOM Level 3 discusses, and adds some tweaks to
support "mixed doms" that I think are
what you are asking about. The idea is to
allow a script operating at the XHTML level
to navigate into the SVG object's DOM
and manipulate it with the Core API.
For example, a script running in the browser
would be able to check and tweak SVG attributes.
It would also be able to get the DOMImplementation
of the SVG DOM so that it could manipulate the
SVG "natively".
"1.1.11. Mixed DOM implementations
As new XML vocabularies are developed, those defining the vocabularies
are also beginning to define specialized APIs for manipulating XML
instances of those vocabularies. This is usually done by extending the
DOM to provide interfaces and methods that perform operations
frequently needed their users.
While the XML Namespaces Recommendation provides a mechanism for
integrating these documents at the syntax level, it has become clear
that the DOM Level 2 Recommendation [DOM Level 2 Core] is not rich
enough to cover all the issues that have been encountered in having
these different DOM implementations be used together in a single
application. DOM Level 3 deals with the requirements brought about by
embedding fragments written according to a specific markup language
(the embedded component) in a document where the rest of the markup is
not written according to that specific markup language (the host
document). It does not deal with fragments embedded by reference or
linking.
A DOM implementation supporting DOM Level 3 Core should be able to
collaborate with subcomponents implementing specific DOMs to assemble
a compound document that can be traversed and manipulated via DOM
interfaces as if it were a seamless whole.
The normal typecast operation on an object should support the
interfaces expected by legacy code for a given document type.
Typecasting techniques may not be adequate for selecting between
multiple DOM specializations of an object which were combined at run
time, because they may not all be part of the same object as defined
by the binding's object model. "
|
