Scott Hernandez wrote: >Yeah, I'm not so sure this should cause an error. I'd be naturally >inclined to go with it; thinking that if it isn't part of the task, >leave it alone. > >Checking for required values is important. The one thing that the XSD >won't do is check for required elements. It will check the form of the >elements and whether attributes are required but that is about it. > >For example, > ><task1 attr1="foo"> > <required attr2="ha"/> ></task1> > >So "task1" will require an "attr1" attribute, and will support a >"required" element with an "attr2" attribute (possibly required-not >checked by "task1" def). But there isn't enough info in the code >attributes to require the "required" element. > Thats what the BuildElement attribute is for. The best example is the TaskFileSet attribute which derives from BuildElement. A TaskFileSet Attribute indicates that there is a child element with the specified name and that the fileset class knows how to load it from Xml. The idea was that it be used the same way that TaskAttribute is used. ie TaskAttribute indicates that there is an attribute ( xml attribute ) on the xmlElement in the build file and whether its required or not. BuildElement should say the same thing about child elements. Whats missing currently is a way to say that there is a collection of a given element as children. As an example the NUnitTask has a list of formatters and or a list of tests. We look for these manually right now rather than using attributes.
I hope this isn't too confusing. I aggree with Gerry that the nameing of some of these attributs could be rationalized. whew - its getting hard to write about some of this stuff what with the word attribute having 2 different meanings Ian _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
