xml-dev - Re: Next Round

[Tyler Baker <tyler@infinet.com>]

james anderson wrote:

> yes, but...
>
> Tyler Baker wrote:
> >
> > Don Park wrote:
> >
> > First, we will need to define a new type, namely Name.
> >
> > public interface Name {
> >   String getPrefix(); // inappropriate
> >   String getLocalName();
> >   String getQualifiedName(); // inappropriate
> >   String getNamespace();
> >   String getExpandedName();
> >   Name clone();
> > }
>
> Neither the prefix nor the qualified name have the same permanence as the
> local name, the namespace and the expanded name. One could well collect all
> prefixes in connection with which as symbol appeared, but the values are of no
> use as the bindings have dynamic extent.
> the prefix and the qualified name need to be handled separately, through an
> interface which combines symbols (here called names) with a dynamic parsing or
> serialization  context.
>
> The other additions have to be modified accordingly: as the prefix has no
> meaning outside of the parser's dynamic context, those interfaces have no purpose.

Very true, but sometimes applications (or even the DOM) may want to preserve the exact
document structure in memory and be able to write out that exact document structure as
well.  That is the only reason for providing the prefix and qualified name methods.

> I know the spec gives you no binding for a prefix to a uri within the dtd, but
> using the prefix is worse setting some binding rules and sticking to them.
> Setting binding rules yields the same results as using the perfix in cases
> which are unambiguous, offers a consistent interfaces, and - by virtue of the
> bindings rules - at least yields defined results in cases where using the
> prefix would yields an undefined result due to ambiguity. Three arguments for
> the approach and none against.

Good point.  I have a bad habit of only thinking positively sometimes (-:

> >
> > Then change the startElement method to:
> >
> > ...
> >
> this, for example, is defined only at the moment the element is being
> processed. outside of the element's scope there is no defined result.
> > String getTypeByQualifiedName(String prefix, String localName);
> > // prefix + ':' + localName
> > String getTypeByQualifiedName(String qualifiedName);
> >
>
> It would be better to use functions like the following (the results of which
> are always defined)

I agree, it is just that there may be reasons I cannot ascertain that an application
may want the exact document structure presented to the application.  Perhaps an XML
tree viewer for example or as I said before the DOM.  Calling
getTypeByQualifiedName(String qualifiedName) would function pretty much exactly as
things are defined now.  In other words, if an XML document does not implement
namespaces, then using this method may be your cup of tea.

> > String getTypeByExpandedName(String namespace, String localName);
> > // namespace + ':' + localName
> > String getTypeByExpandedName(String expandedName);
>
> The former can be combined with a function to determine the uri bound to a
> prefix - if need be. In my experience this latter function is of no use to an
> application, as an application operates is better operating in terms of the
> universal names only.

It can be of use in Java if the entire expanded name is interned and you do your
string comparisons by identity.  It is just a matter of whether you want to process
things like:

if (namespace == "foo") {
  if (localName == "bar") {
    // Do something
  }
}

or else do something like:

if (expandedName == "foo:bar") {
  // Do something
}

Tyler


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/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe 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)