Re: [drools-dev] Schema

You're evading the questions. A complete schema set
has already been created and contributed. A second
effort, almost complete has been reported that
separates the base schema completely from semantic
support schema.

This isn't at all about out of date schemas. This is
the situation now. Why are you driving forward as
though none of that work has been done?

--- Mark Proctor <mproctor <at> codehaus.org> wrote:

> Roger,
> 
> As stated before I started work on the xsds as I
> didn't know about any 
> existing xsds. The original ones had become out of
> date and 
> unmaintained, they still had jelly refences in them,
> so another 
> developer, not me, removed them. I checked the
> mailing list you last 
> showed interest in drools back in March, we've had a
> complete developer 
> turnover (minus bob ofcourse) since then, thats a
> long long time in the 
> opensource world and drools has gone through several
> code maintenance 
> and tidy ups since then in the transition from
> drools 1.0 to drools 2.0 
> - if no active developer seems to be maintaining an
> area of code and its 
> out of date with no one coming forward to maintain
> it, then its going to 
> be deleted. If you want to work in the opensource
> world, learn to love 
> and live with its fluid dynamic nature - like King
> Canute, you cannot 
> hold back the tide.
> 
> The way I see it there are three options:
> 1) Use the xs:any tag and declare a target
> namespace. This was used in 
> your original schemas and is not desirable as the
> user can literally use 
> "any" tag from that namespace, so he/she could add a
> condition where a 
> consequence is required and worse still it couples
> rule.drl to the 
> semantic drls - as you must specify the java, groovy
> and python as 
> available target namespaces. From your original base
> rule file:
> <xs:group name="OptionalRuleChildren">
> <xs:choice>
> <xs:element name="declaration" type="drl-parameter"
> />
> <xs:element name="extraction" type="drl-extraction"
> />
> <xs:element name="condition" type="drl-condition" />
> </xs:choice>
> </xs:group>
> 
> <xs:complexType name="drl-condition">
> <xs:sequence>
> <xs:any namespace="http://drools.org/semantics/java
> http://drools.org/semantics/python" />
> </xs:sequence>
> </xs:complexType>
> 
> 2) Couple base rule.xsd with semantic xsds and then
> use xs:choice. Which 
> I noticed you updated your original schemas to,
> currently on your 
> website use, after viewing mine and calling it
> "knock-off" code. This is 
> not idea, as while it gives better restriction than
> 1), it causes errors 
> messages to appear during rule load time - because
> not all semantic 
> modules will necessarily be in the classpath; hence
> why my reluctance to 
> cart blanche replace what I have now. From your
> current base rule file:
> <xs:group name="Conditions">
> <xs:choice>
> <xs:element ref="java:condition" />
> <xs:element ref="groovy:condition" />
> <xs:element ref="python:condition" />
> </xs:choice>
> </xs:group>
> 
> 3) Use abstract types and substitiongroup. This
> gives us a complete 
> decoupling. rule.xsd enforces the drl structure and
> some validation, 
> like unique keys and extractor targets. Because the
> element types are 
> abstract the user could never use them. The Semantic
> xsd them implement 
> these abstract elements, via substitutiongroup, and
> enforces type and 
> attributes. I belive this to be the correct way to
> do this and have 
> initially documented this at
> http://drools.org/Schema+Validation. 
> Ofcourse there is always room for improvement, and I
> honesty want 
> constructive criticism and good patches, otherwise
> how else can I 
> improve? From rule.xsd:
> <xs:element ref="rules:abstractCondition"
> maxOccurs="unbounded" />
> <xs:element name="abstractCondition"
> type="xs:string" abstract="true"/>
> from java.xsd:
> <xs:element name="condition" type="xs:string" 
> substitutionGroup="rules:abstractCondition"/>
> 
> I actually believe that 3) is something that you
> have been trying to get 
> to working yourself but haven't made publicly
> available yet. from your 
> comment to bob:
> Bob: Mark and Andy are working on breaking the link
> between the core xsd 
> nd the various XSDs for each semantic module
> Roger: We do seem to be working in the same
> direction -- this is exactly 
> what I was talking about in one section of my recent
> comment to 
> user-group asking for help on the Schema
> sub-project. Note, that I also 
> said I've almost got it and defined the one problem
> remaining.
> 
> But then after saying you have a reimaining problem
> you state the 
> following, with regards to my implementation of 3):
> "But it doesn't actually check anything. It's
> "fullyextensible" to the 
> point that it doesn't matter at all what element
> shows up .... it's even 
> less effective than the original schema that at
> least checked for an 
> acceptable namespace. I've solved the problem --
> checking all elements 
> in a drl without referencing any particular
> semantics -- all the way up 
> to the xpath problem in the keyref."
> 
> At what point does 3) allow a user to specify any
> type? I quite clearly 
> define my abstract elements which a semantic layer
> must substitute and 
> then enforce the correct type - so quite clearly
> "that it doesn't matter 
> at all what element shows up" is false.
> 
> However I know I'm not perfect and I'm sure there
> are ways we can 
> improve on this and mistake/bugs I may have created,
> I would love to see 
> what your findings are and the schematron stuff
> looks very interesting - 
> so please lets work together and submit a patch with
> justification for 
> it. Also enough with the "your code, my code"
> milarky, its a group 
> project thus its "everyones" code - all we want is
> for drools to be the 
> best it can be, please help use achieve this by
> submitting patches 
> against a jira with a justification.
> 
> Regards
> 
> Mark D. Proctor
> 
> Roger F. Gay wrote:
> 
>  >The big question is why? A lot of work has been
> done
>  >on the schemas and the technology has already been
>  >developed to a more advanced stage that what
> you're
>  >discussing. Matching schema design with the drools
>  >vision was already taken up more than a year ago
> when
>  >the first schema set was developed. What you're
>  >presenting now is about as close to realizing the
>  >dream as that first schema was for Drools 1.
>  >
>  >I see a lot of work to be done related to the
> schema
>  >(directly and indirectly related – dependent),
> work
>  >that could benefit the drools project immensely.
>  >There's plenty of work for everyone, and I don't
> see
>  >the benefit of spinning the wheels in one place.
>  >
>  >If you're acting as project leader, what's the
> plan?
>  >Have you closed this part of the project to
> outside
>  >contributions? Has a drools-wide decision been
> made to
>  >limit interest in building new products and
> technology
>  >that incorporate drools?
>  >
>  >I have been interested in going a long way with
> 
=== message truncated ===

=====
Correlation does not prove causality.

		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com