: But doesn't sticking with w3c.dom.Element allow the possibility of
: standards based tools (eg XPath implementations) to be used by builders
: if they so wish?
Hmmm... that isn't something i'd considered. You've convinced me.
: >3) I'm still confused about how state information could/would be
: > passed up or down the tree by builders. you mentioned something
: I ripped the ThreadLocal thing out and opted for
: DOMUtils.getAttributeWithInheritance instead. My one scenario I came
: across where I wanted some context passed down was "fieldName" and this
: is handled simply by leaf nodes walking up the w3c.dom.Node tree until
: you find an Element with this attribute set.
Hmm, i can see how that would work in some cases, but it's not very
general purpose. Builders deep in the tree can "look up" at attributes
higher in the tree, but that assumes the state info they want is already
in the XML Elements (allthough i suppose builders higher up could
mutate the attributes on their Element for discovery by lower level
builders ... but that seems sketchy).
It also doesn't address the problem of passing state up the tree ... which
may be a less common case, but it still seems important to support it.
: The addBuilder call shown above should probably be changed to just take
: a Builder object and it should get the root tag name from the
: Builder.getTagName you propose.
Hmmm... can you remind me what i proposed again?
: I am still of the opinion that a self-documenting parser configuration
: ("what XML can I write: is it <tf> or <TermQuery>?") is important,
: otherwise users have to examine parser source code to determine it's
: capabilities. If we make the step of allowing the parser configuration
: to provide metadata about what is required/optional etc we can not only
: produce documentation but also drive a query-building GUI.
that's an interesting idea. i suppose if each builder had a way to return
info about the tags/attrs they supported then a recursive "generateDTD()"
method could be implimented (there would be some trickiness in dealing
with the "classes" of tags ... but myabe it just seems harder to me since
i've never really bothered trying to understand DTDs
that certianly seems like a more easily solvable problem then the
toXmlString(Query) issue (since multiple tags could generate Queries of
hte same type)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
