>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm >X-No-Archive: yes >list-help: <mailto:[EMAIL PROTECTED]> >list-unsubscribe: <mailto:[EMAIL PROTECTED]> >list-post: <mailto:[EMAIL PROTECTED]> >Delivered-To: mailing list [EMAIL PROTECTED] >User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513) >Date: Wed, 17 Nov 1999 16:36:46 -0800 >Subject: Re: Request for Vote: Dom Package Change >From: Pierpaolo Fumagalli <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Mime-version: 1.0 >Content-transfer-encoding: 7bit > >Andy Clark <[EMAIL PROTECTED]> wrote: > >> [...] (I would like >> Xerces to move under the "org.apache.xml" package ...but that's >> a whole separate argument.) > >Rajiv forwarded Stefano's E-Mail sent to Jakarta explaining the reasons of >this. We use the naming described there since a couple of years in the Java >Apache project, the Jakarta project agreed on it, and the XML one "assumed" >it silently. I wouldn't like to rediscuss this thing once again, but if the >XML folks feel this as a strong limitation, the voice cannot pass unheard...
> >> The question to resolve is whether or not people think that the >> DOM implementation is *the* generic DOM for all of the Apache >> XML project. If "yes", then let's move it. If "no", then we >> need to ask if there is a generic DOM. Well if you want to be real generic refer to the interfaces in org.w3c.dom. This way they don't have to even care about which parser is generating the DOM tree. You can always set the implementation via a system property or by a setImpl method name or some such way.. As long as the DOM API is available in the implementation it should work just fine. So having these interfaces in a place makes sense. Not the implementation. That in a true sense would be generic.. Also in reply to Andy about moving to org.apache.xml - xml.apache.org is an umbrella for a lot of xml related stuff in Apache. There is cocoon. fop etc. So in a sense it can be considered sort of a small org in itself. You always use the project / product name as part of your package name and not JUST the org name. Never would a company named Foo come out with a product that has a package name of just com.foo. It will have com.foo.product. I know then the argument comes up why not use org.apache.xml.xerces. For that take a look at Stefano's mail. He describes the reason for not being so explicit. In addition to that as long as the name xerces is well publicised as the java xml parser in apache(which I am sure it already is) it makes perfect sense to have the package name as org.apache.xerces. - Rajiv > >Perfectly agreed... My intention, when I said why don't we move that package >in another place, is that I would like to see a DOM implementation not tied >to the parser or to whatever other component. >Now, I don't have the technical knowledge to say if the one that is in >org.apache.xerces.dom is generic enough, that's you to tell, but IMHO a >generic and unique DOM implementation is nedeed. > > Pier >
