commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Essl <christiane...@yahoo.de>
Subject Re: [HiveMind] nested schemas
Date Tue, 09 Mar 2004 06:21:12 GMT
That's a good point. I've removed all the references to schemas without a 
ids.

A use case would have been an ServiceFactory using BuilderFactory which 
chosses at runtime between different implementations. In generaly if you 
reuse a service having access to it's parameters-schema is not bad.

Apart of this I am not sure how private even the processing part of a 
schema is. Configurations can be accessed by anyone and should therefore 
be considered public. There is no way to express 'no stable result'. 
Schemas for services are defined in the service-point and not in the 
implementation. They are part of the service-interface and implementations 
will have to rely on the processing.

IMO that's just a consequence of combining the processing with the 
xml-defintion. The public xml-def trags the procssing-result into public.

So while I've strong doubts about this promis on stability I agree that 
expressing it explicitly is a good idea. I also agree with you that 
HiveMind is build around use-cases and I've to say that all the use cases 
I can imagine can also be full-filled if recursion is supported and if 
plain elements are returned.

Thank you. Eclosed is my new diff.



On Mon, 8 Mar 2004 17:28:44 -0500, Howard M. Lewis Ship 
<hlshiplists@comcast.net> wrote:

> The act of assigning an id to a <schema> is, in effect, a promise on the 
> part of the developer that
> the <schema> (and the Java objects assembled from contributions to that 
> schema) are stable enough
> for others to reuse.
>
> In the case that no id is provided, it may be an oversight, or it may be 
> that the Java objects are
> not reusable.
>
> Can you give me reasonable examples of why you think this change is 
> necessary? To date, in HiveMind,
> everything really has been driven by real experience (generally, 
> anti-patterns in other software,
> but still).
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Tapestry: Java Web Components
> http://howardlewisship.com
>
>
>> -----Original Message-----
>> From: Christian Essl [mailto:christianessl@yahoo.de]
>> Sent: Monday, March 08, 2004 4:07 PM
>> To: commons-dev@jakarta.apache.org
>> Subject: Re: [HiveMind] nested schemas
>>
>>
>> Thanks for the hint on schema-id!
>>
>> I've added it now. Checking and complaining early :).
>>
>> I removed the configuration-id and service-id atts and have just
>> schema-id.
>>
>> However I still want to access schemas even if they don't
>> provide an id.
>> Therefore in my current implementation I give each schema
>> which has no id
>> set a default id. For configuration schemas 'c:'+config-id,
>> for service
>> schemas 's:'+service-id. (This ids can also be used in
>> <schema id-ref="">
>> ).
>>
>> What do you think of that, is this too much change?
>>
>> Thanks,
>> Chris
>>
>> --
>> Christian Essl
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org



-- 
Christian Essl 
Mime
View raw message