[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. 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
|
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
|