>> >That leaves us two solutions (that I can think of). Either enhance >the >> >code attributes or add code to supply this extra information. >> > >> >Code Attributes >> >Pros: Simple, Easy to use, intuitive? >> >Cons: Harder to extend, need to take into consideration each new code >> >attribute in core/framework, get much more complicated as the xml >does. >> > >> I'd lean towards more informative attributes. > >I do too. I think they will offer the solution to 80-90% of the >problems. I can only imagine a few situations where someone might want >to add more information by directly affecting the XSD generation. > >We will need to allow access to the XSD Generation process. But we can >address that when we encounter a scenario that attributes don't handle.
This reminds me of the serialization stuff MS has done in the framework itself. To be serializable, class have to simply use the SerializableAttribute. however, to control their own serialization, classes can implement ISerializable, in which case the can do it themselves. So how about a IXsdGenerator ( or whatever you wanna name it ) interface that signifies that this doodad needs to make a few adjustments to the xsd? I'm not going to propose ( or even think of ) the details of the interface just yet... I'm just proposing an already-in-use pattern to solve this kind of problem. ____________ Andy Smith Chief Code Monkey _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
