Ok fair enough. I still think that the URI specified at the "typedef" task should be restricted, if only to allow future versions of ant to support other forms of processing based on URIs without affecting build scripts that specify URIs using "typedef". I do not see that this is a big restriction (but I could be mistaken!). The restriction needs to be specified - it could be that the uri must start with "antdef:", as the typedef is defining ant types, but I am happy with any restriction.
So I think that at least initially, the uri should be restricted until feedback is received from the community. Peter On Tuesday 20 May 2003 08:34, Costin Manolache wrote: > peter reilly wrote: > > There are a number of issues here. > > > > 1) are build script authors allowed to specify arbitary > > URIs for ant type definitions? > > I do not think this is a good idea. > > I agree - I also preffer URIs that are interpreted in a certain way ( > package names ), however we could support both. > > A URI that starts with "antlib:" will be parsed and the package used. > Other URIs will be treated in a different way - either as arbitrary strings > and matched against an explicit definition ( like the xml catalog ), or > we may discover better things in future. > > > 2) what should ant do with URIs that it does not recognize? > > > > a) use current method - unknown elements > > That seems the most reasonable and safe - it is what it does with unknown > elements ( in no-namespace case ), I don't see why it should be different. > > > b) ignore them > > c) explicty say that the ns uri is not supported > > d) convert them to Text in task/typedefs (the suggestion below) > > > > I would prefer b) as it allows other processing of the xml content - > > say in an xml processing pipeline. d) is also nice. > > > > > > > > 3) Should all processing outside Project/Target be done by > > PH2#ElementHandler? > > I think one should be able to plug in handlers for different URIs, or > > URI patterns. My UnknownUriHandler is an (possibly not very good) > > example. > > My preference would be to not put any more functionality in ProjectHelper2, > but operate on the tree. PH2 should just create the tree. > > > Costin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
