Re: DESIGN PROPOSAL: Java XMLIterator
> First question: Are you prepared to put pullax into the public domain? If > so it may be a good starting point for the pull-API that John is > suggesting. 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 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. Currently I'm using the BSD copyright, which is about the most liberal open source license. In my experience, the BSD license is generally more acceptable than public domain. Some organizations find the absence of a copyright holder (as is the case with public domain code) unsettling; public domain also provides no protection from removal of no warranty information or from use of the author's organization in advertising. > Second, I followed your invitation to look at the JavaDoc on your web site > . I haven't had a chance to look at it in detail, but one of the first > things I noticed was the XmlInputSource class . 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. 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. James
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format