Quoting Peter Donald <[EMAIL PROTECTED]>:
> Hi,
>
> This sounds familiar - was it you or Fede who said we would never need
> Namespace info last time ? ;)
>
> On Fri, 21 Sep 2001 04:00, Berin Loritsch wrote:
> > The delimna is that we need to provide a solution that is:
> > * Easy to use
> > * Provides minimal impact on the current API
> > * Satisfies a need
> > * Easily extendable
>
> works for me.
>
> > The Configuration object's use can be further helped by the
> > following additional information: Namespace and Qualified name.
> > The Configuration object specifies the method getLocation().
> > It's use is not well documented, so it can be purposed to record
> > the namespace.
>
> *cough* - I use it in a lot of my proggies to specify where an error
> occured
> as do some of the exception reporting in core Avalon. It allows us to
> give
> meaningful error messages (ie "Missing attribute foo at
> myconfig.xml:20").
>
> > The name of the component would be bound to
> > the local name in the XML. The last remaining issue is the
> > prefix or qName. Because the prefix is not as important as
> > the local name or the namespace, a new accessor method can be
> > provided called "getExtendedName()". It would work like this:
>
> If we were to go down this path I would possibly prefer something like
>
> getNamespace()
> class Namespace
> {
> String prefix;
> String uri;
> }
>
> > This does not interfere with the current API, and only provides
> > one additional method. What it does allow is the ability to use
> > industry standards for configuration (WSDL, WSDD, etc.) and to
> > take advantage of dynamic validation of our configuration schemas.
> > XML parsers can read the configuration information and validate
> > the file based on the various schemas, throwing exceptions when
> > the configuration is invalid.
>
> They can still do that at the moment without any support from
> Configuration
> object. So Schema/DTD is good but doesn't madate changes in
> Configuration
> object.
>
> The argument goes that all configuration for a single object will always
> be
> in one namespace. Thus it is up to the container to do validation et al.
> The
> reason I wanted Namespace recorded in Configuration was when we had
> hierarchial Configurations. ie Component A contains B which contains C.
> If
> config for A also contains config for B (and then C) then we would
> namespace
> separation.
>
> However as it stands that was identified as a bad pattern because you
> could
> never fully validate C (or B) without initializing A. And considering
> initialization of A comes after validation of As configuration we had a
> problem.
>
> So what do you think of that ?
>
> > Each persistence mechanism must follow its own rules. However, it is
> > conceivable to convert your persisted data into XML which is then able
> > to be handled in the expected manner. This reduces the amount of
> learning
> > curve, hides the details of the persistence mechanism, and allows you
> > to focus on the task at hand.
>
> Thats what I was planning on doing (when I got around to it). ie
> DB/LDAP/XML
> to SAX, SAX to Configuration object (and vice versa).
>
> > It also allows for new tools to be developed. Tools are used to
> augment
> > the development process, the configuration process, or the deployment
> > process. Tools are not used directly in the run-time system--so they
> > should not be part of any of our existing projects.
>
> Agreed. As a sidenote has anyone looked at Merlot (opensource XML
> editor). It
> looked good last time I looked at it however it only allowed structure
> specified through a DTD (not XSchema). I was wondering if there is any
> alternatives out there?
XEmacs ;)
Giacomo
>
> --
> Cheers,
>
> Pete
>
> --------------------------------------------
> Beer is proof that God loves us and wants
> us to be happy. -- Benjamin Franklin
> --------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
