Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 11692 invoked from network); 12 Nov 2001 14:46:19 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 12 Nov 2001 14:46:19 -0000 Received: (qmail 10872 invoked by uid 97); 12 Nov 2001 14:46:15 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 10856 invoked by uid 97); 12 Nov 2001 14:46:14 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 10828 invoked from network); 12 Nov 2001 14:46:13 -0000 Message-ID: <3BEFE10C.2C53F354@apache.org> Date: Mon, 12 Nov 2001 09:47:40 -0500 From: Berin Loritsch X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "avalon-dev@jakarta.apache.org" Subject: Summary of issues Avalon Framework 4.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Right now, the changes to the Logging part of Avalon are accepted, and no issues have been voiced. However, the Namespace incorporation has proven to be _very_ difficult. The reason being is trying to get everyone's oppinions to come together. We have not been able to do this yet. Let me start by declaring the current contracts surrounding the Configuration element, and how namespaces will extend that contract. Configuration ------------- * Read-Only * Represents structured heirarchy * Configuration != XML * Simple interface and usage by default Adding namespaces to the system will require one additional string, as the Namespace URI should be the differentiating piece of information. Namespace != location. The Namespace should be used to point to a validation class or schema of some sort. This allows us to support fully validatable configuration trees. This will be a future requirement, but it should be the desired purpose. We already have a Location string that is used to record the URI of the source and possibly the line number in the file. Therefore, I propose we do away with the Namespace class itself, and merely represent the Namespace with a String showing the URI to a validation/proposed validation source. Lastly, we should NOT support attributes with a different namespace than the parent element. This is not a clean solution for configuration. We CAN explore a different solution for this type of thing (i.e. magic values are used by the container--so the container needs to get at the values and not propogate them. NOTE: We have previously discussed DOM integration, semi-structured configurations, and namespaced attributes. The people who were developing Avalon at the time ALL came to the mutual conclusion that for the purposes of CONFIGURATION, these things would add too much complexity, to the point that the implementation would not be worth it. The Configuration object is designed to be a SIMPLE, LIGHT-WEIGHT object. -- "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin -- To unsubscribe, e-mail: For additional commands, e-mail: