> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jaroslaw Kowalski > > My vote: let's NOT support it - I'd say more - let's disallow it. > Simplicity is an important thing. > > The only advantage of XML namespaces I see is technical beauty and XSD
> schema support for extensible intellisense - IMHO it's not worth it. The main reason for implementing namespaces isn't elegance or schema support... funnily enough, it's for namespaces :-) Lets say you use various third-party libraries containing tasks for NAnt. The ImageFoo library contains a task compress-image, which takes a bitmap file and converts it to a jpg, with attributes to specify compression levels and such. One day, you find that you need to use the NAntFileMagic library, which also contains a compress-image task... this one takes a fileset of images of any format, and creates a multiple-page png file which is gzip-encoded (for example... does png even support multiple images per file? (-; ) Without namespaces, you can't (realistically) use these libraries together. However, if you could explicitly namespace each library, then you can unambiguously use all of the features of both libraries. For example (using namespace syntax similar to Ant): <loadtasks assembly="ImageFoo.dll" uri="http://tempuri.org/imagefoo"; /> <loadtasks assembly="NAntFileMagic.dll" uri="http://tempuri.org/file-magic"; /> <ifoo:compress-image xmlns:ifoo="http://tempuri.org/imagefoo"; ... /> Having said all of this, I tend to agree with Jarek in that namespaces aren't a particularly good way of doing this... at least, not the way Ant does it. Particularly clumsy is the need to specify the URI at least twice. I can see two obvious alternative syntaxes that are cleaner than the above. Note that they are put here for comment, I'm not necessarily recommending either of these approaches. First, the proprietary method, not using any special xml features... the way Ant decided not to go. To demonstrate using the above example: <loadtasks assembly="ImageFoo.dll" namespace="ifoo" /> <loadtasks assembly="NAntFileMagic.dll" namespace="magic" /> <ifoo:compress-image ... /> Pros: * Concise * Single definition of namespace * No confusing uris, with no purpose other than as a name Cons: * Not valid xml (undeclared namespace?). Xml validation errors can be removed by declaring the namespace (xmlns:ifoo="http://tempuri.org/ifoo";) somewhere in the build file, but it's annoying to have to. Second, use namespaces more as they were intended (As I interpret the intention for xml namespaces). Using the same example: <ifoo:compress-image xmlns:ifoo="assembly:ImageFoo.dll" ... />[1] Pros: * Single definition of namespace * The namespace uri is meaningful cons: * The namespace has side-effects, being loading of tasks, functions etc. There's actually an extra issue in using namespaces in a fashion similar to xml namespaces, whatever the approach... In (my understanding of) the current behaviour of loadtasks, any loaded tasks are available at any point in the build system that occurs after the task executes. Xml namespaces, on the other hand, are only visible in the defining element and all children. While this itself isn't a major problem, it lends itself to the concept of *redefining* a namespace... so a child element could redefine the namespace with a different assembly - once the child element has completed executing, the namespace returns to the parent's definition. This is probably a really bad idea, because it would be hard to understand or maintain build files. But if a build definition were spread across multiple included and called files, and if different people author various files, it's not an impossible circumstance. Finally, would this concept of namespaces introduced to tasks replace, extend, or not affect the current concept of namespace in functions? ie- load an assembly containing functions, specify the namespace 'myfoo'. If the assembly contains a function mystring::to-lower-case, would the function then be referenced by myfoo::mystring::to-lower-case? Also, I imagine that the use of namespaces may make the schema task more difficult to maintain, depending on the implementation chosen... Regards, -- Troy Disclaimer Message: This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. To the maximum extent permitted by law, Immersive Technologies Pty. Ltd. does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
