Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 71836 invoked from network); 30 Sep 2002 18:56:08 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 30 Sep 2002 18:56:08 -0000 Received: (qmail 25652 invoked by uid 97); 30 Sep 2002 18:56:50 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 25636 invoked by uid 97); 30 Sep 2002 18:56:49 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 25624 invoked by uid 98); 30 Sep 2002 18:56:48 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: From: Dominique Devienne To: "'Ant Developers List'" Subject: RE: xml namespace support in ant2 Date: Mon, 30 Sep 2002 13:56:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Frankly, this sounds great Costin. But, from what you are writing below, it sounds that you have thought a lot on the issue of antlibs and use of namespaces in Ant, yet I haven't read anything about this prior to this particular message... Did I miss the discussions on it? I'm afraid that once more a big chunk of good code will get vetoed because not thoroughly discussed by the community before-hand, and not easily digestible by pieces. Sure, having something already implemented that works is a great base for discussions, but looking back at what happened not too long ago with the Ant2 proposals, maybe it isn't enough after all. In summary, I'd like to be able to hear more from you about how you want to tackle antlibs, imports, etc... so that maybe I get my views / use cases in from the users perspective, and also (and maybe foremost) so that some kind of consensus agrees it's the right direction. But maybe I'm just ignorant of how Open Source project work again... --DD -----Original Message----- From: Costin Manolache [mailto:cmanolache@yahoo.com] Sent: Monday, September 30, 2002 12:33 PM To: ant-dev@jakarta.apache.org Subject: RE: xml namespace support in ant2 My opinion: 1. I hate using schema for validation. XML is not the only way to use ant - there are already projects using ant tasks as beans, and it's a good code reuse. Besides, schema is still slow ( and will allways be - due to it's complexity). Even Relax or simpler schemas can't ever beat the if() in the task, which also cover the use of the beans. 2. However schemas are good for documenting the task and for possible tools. As long as we don't use them for validation ( which I'll -1 as strong as I can ). 3. The embed proposal uses SAX2, but it is not doing anything ( yet ) with the namespaces. My original plan was ( and still is ) to use the namespace as an ID, and use it to locate the task definition using getResource(). For a task in NS, I would look up META-INF/ant/encoded(NS)/SOMETHING - and locate the description of the tasks in that namespace and additional metadata. The descriptor should support both properties (for simple cases) and an XML form. 4. A very tricky issue is the syntax of the ID. We can use a meaning-less string, or a URL that can be used to download the lib. Even in the first case ( arbitrary string ) we can have a 'antlib registry' - but it would be extra overhead. I know there are many (strong) opinions on this. 5. Even if ns is added, most people will still prefer to use the default namespace. It's just much easier to type and use ( at least IMO - and from what I've seen ). Should we restrict the default ns to ant core tasks and force everyone to use ns for extensions ? I don't think so. 6. Namespaces should be used instead of 'taskdef' whenever possible ( i.e. the descriptor ). Costin Wannheden, Knut wrote: > This reply is a little bit late (just got back from holiday) but I think > it's an important topic and I was wondering if anybody has given this more > thought in the meantime. > > With some minor adaptions I think your general description of the usage of > XML namespaces sounds very good. > >> -----Original Message----- >> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org] >> Sent: Freitag, 6. September 2002 23:54 >> To: Ant Developers List >> Subject: Re: xml namespace support in ant2 >> >> So instead we could say that >> 1) all ant: namespace elements are core ant. >> > > Well, what the namespace prefix is in the buildfile is really up to the > user. It's just the URI that matters. So all of thw following should > work: > > > > > > > > But specifying it as the default namespace as in the first example or > using "ant" as the prefix will probably be the most common usages. > > When you say "core ant" I assume you're talking about , , > all core and optional tasks and types in the distribution. > >> 2) different namespaced elements have to be defined before use as >> taskdefs, typedefs or antlibs, and ant treats them accordingly >> > > I think saying it the other way around would be more correct. I.e. Custom > tasks and types have to be declared to use a different XML namespace. > >> 3) all namespaced tags that are not declared as in (2) must >> be declared >> beforehand as , >> so that the >> Ant ProjectHelper can use that particular Handler to process the >> extension. A convenient nullHandler is created when the >> handler is not >> specified. >> > > What would this be used for? Isn't it enough with task and type > extenstions? Other extensions would certainly raise confusion... > > The primary benefits I see of using XML namespaces the described way are: > > - Mechanism to avoid name clashes of different tasks and types > - Schemas (grammars) could be written for Ant buildfiles covering the Ant > core elements and external tasks and types. > > The schemas in turn would allow the validation of tasks and types to take > place externally and at an earlier stage. With externally I mean that the > tasks and types wouldn't need code to do the validation themselves. > > At a later stage the schemas could maybe even be the basis for the > documentation. Also, the different usages of a task could maybe be bound > to the different processing modes somehow. > > Playing some with RELAX NG and Sun's MSV validator I found that it was > quite > easy to specify grammars for the different Ant tasks and types. Even > writing grammars that support other namespaces isn't very hard. That way > a grammar which validates buildfiles using other namespaces for external > tasks > and types can be constructed easily. It should also be quite easy to > allow external tasks to specify their own grammar for validation. > > Any thoughts? > > Cheers, > > -- > knut -- Costin -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: