[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

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


> 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
> 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
> > [1].  I haven't had a chance to look at it in detail, but one of the
> > 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.
> > 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
> 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
> 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
> 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
> 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
> 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.



Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.