(I keep getting confused when you write "build in" and probably mean "built-in".)
Yes I mean built-in thank you - you know my English :-)
The schema right now is pretty much a very stripped down version of RelaxNG.
The schema supports <element> and <attribute> and a "required" attribute for
<attribute>. To keep things simple I think the default schema shouldn't be
a whole lot more complicated. The next most important thing, IMHO, would be
an equivalent of RelaxNG's <choice> and <group>. But like you I think that
both the schema language and processing should be pluggable. Ideally as
HiveMind services of course!
I take it that changes to these parts would be for HiveMind 1.1.
--knut
You are right thinks should be kept simple and <choice> and <group> would help.
May be the pluggable processing could make it also in the 1.0 release. Just give a way to get the unparsed elements and than anyone can implement a Service which reads it's processing rules form a configuration and than takes the Elements form the contribution and processes them. (These services can be used by than like any other service).
I think to get the Elements something like this would be sufficient: ConifurationPointImpl{
private List _contributingElements;
synchronized List getContributingElements(){
if(_contributingElements != null)
return _contributingElements;
_contributingElements = new ArrayList();
int count = _contributions.size();
for (int i = 0; i < count; i++)
{
Contribution extension = (Contribution) _contributions.get(i);
_contributingElements.addAll(extension.getElements());
}
return _contributingElements;
}
}
I also think the current SchemaProcessorImpl could with out much change swithed to an only validating parser. Just add a boolean onlyValidating and call out to the rules only when the property is false.
-- Christian Essl http://jucas.sourceforge.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
