Peter Donald wrote:
>
> Hi,
>
> This sounds familiar - was it you or Fede who said we would never need
> Namespace info last time ? ;)
It might have been Fede...
> > 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").
Ok.
> > 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;
> }
Then if we go down that path, I would like to see something like this:
getXMLName()
class XMLName
{
String getLocalName();
String getNamespace();
String getQualifiedName();
}
> > 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.
This is true--but the applications that use industry standard configurations
need to see the namespaces. That does mandate changes.
> 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 ?
So your saying if we divide B over C we would come up with the theta of A?
You lost me there.
WSDL declares information for how to contact a specific SOAP target. As such
it requires you to embed Schema information as well as other information that
must be namespaced. Working directly with SAX is inconvenient, and DOM is
expensive. Both of them do not offer type-safe accessors. Hense all the benefits
of our Configuration object.
> > 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).
We have vice versa now! We just don't have DB/LDAP yet.
> > 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?
A long time ago. It proved to be unweildy then--I don't know how it is faring
now.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
