[
Lists Home |
Date Index |
Thread Index
]
- From: David Megginson <david@megginson.com>
- To: "xml-dev@ic.ac.uk" <xml-dev@ic.ac.uk>
- Date: Mon, 20 Dec 1999 15:01:18 -0500 (EST)
Stefan Haustein writes:
> David Megginson wrote:
> > Stefan Haustein <stefan.haustein@trantor.de> writes:
> > > OK, what about
> > >
> > > void startElement(String localName, AttributeList attr,
> > > NameSpaceContext nsc)
> > >
> > > NameSpaceContext could be unmutable and thus be reused while unchanged.
> > > I could still remember all parameters since there is only one more at
> > > the end :-)
> > >
> > > The parser would only need to check if the NSC has changed and could
> > > reuse the same object otherwise.
> >
> > How would that help with attribute lists?
>
> Where is the problem in adding something similar to the attribute lists,
> e.g.:
>
> - getLocalName
> - getType
> - getValue
> - getNameSpaceContext
>
> NameSpaceContext could provide access methods for the namespace URI and
> the prefix. It also
> could provide a method "getName (String localName)" that builds the full
> name if needed.
I'm not sure that this approach buys us much, in the end. You'd need
something like this:
public class AttributeList
{
public int getLength ();
public NamespaceContext getNamespaceContext (int i);
public String getLocalName (int i);
public String getType (int i);
public String getValue (int i);
public String getType (NamespaceContext c, String localName);
public String getValue (NamespaceContext c, String localName);
}
That does not seem substantially different than James Clark's
proposal:
public class AttributeList
{
public int getLength ();
public String getNamespaceURI (int i);
public String getLocalName (int i);
public String getType (int i);
public String getValue (int i);
public String getType (NamespaceURI c, String localName);
public String getValue (NamespaceURI c, String localName);
}
The only difference (other than being able to add methods into the
NamespaceContext class) is that you want the application to keep track
of what the current Namespace URI is rather than having the parser
keep track of it.
The main choice, then, is between the following (imagine that "foo" is
a full URI):
startNamespace("foo")
startElement("bar", atts)
character("Hello, world!")
endElement("bar")
endNamespace("foo")
and
startElement("foo", "bar", atts)
characters("Hello, world!")
endElement("foo", "bar")
I cannot say that I have an extremely strong preference either way,
but if (as some people suspect) documents will consists of elements
from many Namespaces mixed together, the latter might be a little more
efficient.
What does everyone else think?
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|