org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Egon Willighagen
Hi all, working on dh_java i encountered this: Duplicate library path: org/w3c/dom in both lib-dom-java and lib-openxml-java,libxerces-java! In other words, the org.w3c.dom classes are given in three packages... They probably have some version differences, but it seem not correct that this

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Andrew Pimlott
On Wed, May 30, 2001 at 03:25:09PM +0100, Toby Speight wrote: AIUI, the packages in question simply bundle W3C's interfaces[1] (unchanged - W3C's licence may require this) I was curious about this, and I would like to ask if there is any consensus on how this affects free software. For

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Andrew Pimlott
On Wed, May 30, 2001 at 09:08:03PM +0200, Egon Willighagen wrote: On Wednesday 30 May 2001 20:48, Andrew Pimlott wrote: It is fine to split packages into the official API classes, and supporting classes. However, it is not fine to say that there can be only one official API classes

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Egon Willighagen
On Wednesday 30 May 2001 21:14, Andrew Pimlott wrote: On Wed, May 30, 2001 at 09:08:03PM +0200, Egon Willighagen wrote: On Wednesday 30 May 2001 20:48, Andrew Pimlott wrote: It is fine to split packages into the official API classes, and supporting classes. However, it is not fine to

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Eric Schwartz
[EMAIL PROTECTED] (Andrew Pimlott) writes: On Wed, May 30, 2001 at 01:03:48PM -0600, Eric Schwartz wrote: [EMAIL PROTECTED] (Andrew Pimlott) writes: While this does allow modification of the software, it effectively says that when you modify it, you must break the API. This seems

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Stefan Gybas
On Wed, May 30, 2001 at 10:57:13AM +0200, Egon Willighagen wrote: But if they are different implementations they should not use the same namespace... (see below) But they implement the same interface (DOM in this case) and the XML for Java standard says that the DOM interface classes have to

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Toby Speight
0 In article [EMAIL PROTECTED], 0 Egon Willighagen URL:mailto:[EMAIL PROTECTED] (Egon) wrote: Egon working on dh_java i encountered this: Egon Egon Duplicate library path: org/w3c/dom in both lib-dom-java and Egon lib-openxml-java,libxerces-java! Egon Egon In other words, the org.w3c.dom classes

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Egon Willighagen
On Wednesday 30 May 2001 11:16, Stefan Gybas wrote: On Wed, May 30, 2001 at 10:57:13AM +0200, Egon Willighagen wrote: But if they are different implementations they should not use the same namespace... (see below) But they implement the same interface (DOM in this case) and the XML for

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Egon Willighagen
On Wednesday 30 May 2001 12:19, Toby Speight wrote: 0 In article [EMAIL PROTECTED], 0 Egon Willighagen URL:mailto:[EMAIL PROTECTED] (Egon) wrote: Egon working on dh_java i encountered this: Egon Egon Duplicate library path: org/w3c/dom in both lib-dom-java and Egon

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Tollef Fog Heen
* Egon Willighagen | Surely then the dependency will be on ( lib-dom-java | lib-openxml-java | | libxerces-java ), since having any of those will satisfy the runtime? | | This will indeed be the outcome of dh_java... A virtual package might be appropriate here - maybe also making a standard

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Stefan Gybas
On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote: Surely then the dependency will be on ( lib-dom-java | lib-openxml-java | libxerces-java ), since having any of those will satisfy the runtime? This will indeed be the outcome of dh_java... I don't think this will work.

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Toby Speight
0 In article [EMAIL PROTECTED], 0 Egon Willighagen URL:mailto:[EMAIL PROTECTED] (Egon) wrote: Egon Stefan argued that interface and implementation should not be Egon seperated: Egon Egon The classes for interfaces might be identical for all Egon containers but at Egonleast the exception

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Eric Schwartz
[EMAIL PROTECTED] (Andrew Pimlott) writes: For interfaces, it may be ok to require only one instance (even that is arguable), but for the classes, it is not fair to allow only one implementation. Argh, I just deleted the mail showing who suggested this, but I really like the idea of using

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Andrew Pimlott
On Wed, May 30, 2001 at 03:25:09PM +0100, Toby Speight wrote: AIUI, the packages in question simply bundle W3C's interfaces[1] (unchanged - W3C's licence may require this) I was curious about this, and I would like to ask if there is any consensus on how this affects free software. For

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Andrew Pimlott
On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote: But it might indeed be good to place the interface classes in a seperate jar/package... this would enforce that the implementation *does* implement the actual interface, and not some look-a-like... I may have misunderstood what

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Eric Schwartz
[EMAIL PROTECTED] (Andrew Pimlott) writes: I was curious about this, and I would like to ask if there is any consensus on how this affects free software. For example, the copyright notice at http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/copyright-notice.html says

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Egon Willighagen
On Wednesday 30 May 2001 20:48, Andrew Pimlott wrote: On Wed, May 30, 2001 at 01:54:52PM +0200, Egon Willighagen wrote: But it might indeed be good to place the interface classes in a seperate jar/package... this would enforce that the implementation *does* implement the actual interface,

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Andrew Pimlott
On Wed, May 30, 2001 at 01:03:48PM -0600, Eric Schwartz wrote: [EMAIL PROTECTED] (Andrew Pimlott) writes: While this does allow modification of the software, it effectively says that when you modify it, you must break the API. This seems like an onerous requirement. Modifying it will

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Egon Willighagen
On Wednesday 30 May 2001 21:14, Andrew Pimlott wrote: On Wed, May 30, 2001 at 09:08:03PM +0200, Egon Willighagen wrote: On Wednesday 30 May 2001 20:48, Andrew Pimlott wrote: It is fine to split packages into the official API classes, and supporting classes. However, it is not fine to say

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Eric Schwartz
[EMAIL PROTECTED] (Andrew Pimlott) writes: On Wed, May 30, 2001 at 01:03:48PM -0600, Eric Schwartz wrote: [EMAIL PROTECTED] (Andrew Pimlott) writes: While this does allow modification of the software, it effectively says that when you modify it, you must break the API. This seems like

Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!

2001-05-30 Thread Andrew Pimlott
On Wed, May 30, 2001 at 02:31:17PM -0600, Eric Schwartz wrote: No, no, I mean what they seem to be saying is that you cannot modify the classes that define the API to either extend or contract the scope of the API. My interpretation of what they're saying is thus: Anything that currently