[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: pullax licence and XmlInputSource [was DESIGN PROPOSAL: Java XMLIter

• To: "James Clark" <jjc@j...>,"John Cowan" <jcowan@r...>,<xml-dev@l...>
• Subject: Re: pullax licence and XmlInputSource [was DESIGN PROPOSAL: Java XMLIterator]
• From: "Rob Lugt" <roblugt@e...>
• Date: Tue, 18 Dec 2001 13:25:06 -0000
• References: <996674472.1008702101@[192.168.0.173]>

>
> I have no desire to retain any intellectual property rights to pullax.

Great.

> However, it is not entirely clear to me that the public domain is the best
> place for a "standard" API. It might be better to assign the copyright to
a
> suitable organization (e.g. OASIS, Sun) to ensure appropriate change
> control.   However, if the consensus is that public domain is best, I am
> happy to go along with that.

My main concern would be that anybody was free to implement the API for free
or commercial purposes.  I suggested public domain as this would mirror the
SAX approach and I presumed that "public domain" was chosen for SAX for a
good reason.  But I think you make a good point about change control.  I
have seen some of the OASIS processes at work and it does seem to work well.

> > Second, I followed your invitation to look at the JavaDoc on your web
site
> > [1].  I haven't had a chance to look at it in detail, but one of the
first
> > things I noticed was the XmlInputSource class [2].  I don't understand
> > what this class is supposed to achieve as it doesn't have any methods.
I
> > see it has three sub-classes, each one offering a subset of a SAX
> > InputSource - but without a common interface how can a parser use a
> > XmlInputSource?  Unless I'm mistaken it will have to cast it into one of
> > the known sub-classes, which isn't very attractive.  Also, why is it a
> > class rather than an interface?
>
> Let me explain what I'm trying to achieve.  I want to allow the input to
> the scanner to be specified in one of three ways:
>
> 1) in the same way as in an entity declaration, using a system identifier,
> a base URI to be used to resolve the system identifier into an absolute
URI
> if the system identifier is relative, and, optionally, a public identifier
> (this corresponds to the XmlExternalId class)
>
> 2) as an InputStream, optionally with a URI specifying the URI from which
> the InputStream was retrieved which will serve as the base URI of relative

> URIs occurring in that entity (in the absence of xml:base attributes), and
> optionally with an encoding to be used (if missing, the encoding is
> autodetected) (this corresponds to the XmlInputStreamInputSource class)
>
> 3) as a Reader, optionally with a URI specifying the URI from which the
> Reader was retrieved which will serve as the base URI of relative URIs
> occurring in that entity (in the absence of xml:base attributes), and
> optionally with an encoding to supply the [character encoding scheme]
> infoset property of the document info item (this corresponds to the
> XmlReaderInputSource class)
>
> Also I want the entity resolver to be able to return one of these three
> kinds of thing.
>
> I don't like combining these three different kinds of thing into one
class,
> because I think it makes the semantics less crisp.

I can understand your reasons, but I don't think the benefit in 'semantic
crispness' justifies the awkwardness in implementation.
Wouldn't 3 constructors, each offering one of the sets of attributes above,
provide sufficient 'crispness'?

>
> The key to the current design is that XmlInputSource has a constructor
with
> package level access.  This means that the only possible classes that can
> derive from XmlInputSource are those in the com.thaiopensource.pullax
> package, specifically XmlExternalId, XmlInputStreamInputSource and
> XmlReaderInputSource.  Thus using the type XmlInputSource is just a trick
> to get the union of these three classes; such a type is necessary for
> expressing the return value of XmlEntityResolver.resolve.  When a parser
> implementation receives an XmlInputSource it will have to check which of
> these three classes it is an instance of, and cast it accordingly.
> Admittedly this is a bit icky; I prefer APIs not to require clients to
> cast.  In mitigation I would plead that it's the parser implementor rather
> that the parser user who is being forced to cast.  One possibility would
be
> to add
>
>   XmlExternalId toExternalId();
>   XmlInputStreamInputSource toInputStreamInputSource();
>   XmlReaderInputSource toReaderInputSource();
>
> methods to XmlInputSource where exactly one of these would return a
> non-null value.  For a C++ interface I would certainly prefer to have
those
> methods rather than rely on RTTI, but for Java it's not clear to me that
> it's worth adding them.

I am coming from a C++ perspective, but I believe that down casting should
be kept to a minimum, no matter what the language.

Regards
~Rob

• References:
  • Re: DESIGN PROPOSAL: Java XMLIterator
    • From: James Clark <jjc@j...>

• Prev by Date: RE: URI for class names and native data types
• Next by Date: Re: DTD problem
• Previous by thread: Re: DESIGN PROPOSAL: Java XMLIterator
• Next by thread: SPKI-XML Certificate Structure
• Index(es):
  • Date
  • Thread