Back to XObjects was XLink - where a
David Brownell
db at Eng.Sun.COM
Fri Nov 13 18:43:37 GMT 1998
Responding to Graham's comment about binding elements to classes, I wrote:
>
> I've got an API driven approach, which could be driven based on config
> files using an XML syntax like the one I suggested a while back. But
> the API can also be driven in other ways, too. ("Element Factory", an
> interface that can be implemented in many ways. I'll post more later.)
It's "later", after a busy Thursday and a morning cuppa Java ...
// to customize DOM tree building
public interface ElementFactory {
// like DOM createElement, used with namespaces disabled
ElementEx createElementEx (String tag);
// ... namespace aware version
ElementEx createElementEx (String uri, String tag);
}
// implemented by elements and attributes for namespace support
public interface NamespaceScoped extends Node {
// returns "local part" of node name, no prefix
String getLocalName ();
// returns URI of namespace, null for default
String getNamespace ();
}
// extended element functionality
public interface ElementEx extends Element, NamespaceScoped {
// namespace-aware
String getAttribute (String uri, String name);
// namespace-aware
Attr getAttributeNode (String uri, String name);
// basic delegation hook
Object getUserObject ();
// basic delegation hook
void setUserObject (Object obj);
// has more, for other purposes ...
...
}
That "user object" bit is a delegation hook; it's just stored for use by
applications. Supports many-to-one association of elements to objects in
an application model, no backlink. I don't know if it suffices, but I
suspect that any more would become specific to some problem domain.
For the moment, I'm not listing the DocumentBuilder bit here. Basically,
you can feed an ElementFactory in to a DocumentBuilder and it'll use it
when building the DOM tree; if you don't, it has defaults. And there's a
simple table-driven implementation that's easily customized. (Maybe it'll
learn a standard "config file" syntax -- in XML of course!)
Other implementations are clearly possible, including ones using heuristics
like those like James Anderson posted.
- Dave
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev
mailing list