On Friday 09 May 2003 04:08, Costin Manolache wrote: > peter reilly wrote: > > Using property files is nice but with new attributes > > to typedef (adaptor for example) it would be better to > > use an xml file/resource. > > I think we already agreed on XML - there is no reason to continue > adding arguments. > > > This should be independent of using antlibs/jars or XML ns. > > Hence I think that the root element name should not be > > "antlib" as this implies more baggage. > > (Also my work in progress implementation uses an ant task > > for the xml parsing and the root element name is the task > > name ;-)). > > That's what I would do too ( and why I suggested using ant xml > processing for the antlib descriptor ) :-) > > What "baggage" are you talking about ? Antlib is what we are > trying to do, it would be confusing to use another name for > the root element.
The "baggage" is that "lib" is normally associated with jar files. > > >> > 1) the code to handle XML namespaces in ProjectHelper2 is > >> > not yet complete. > >> > - namespaces of attributes is not handled yet - the > >> > code uses getQName() on the attributes and does > >> > not pass the URI of the attributes to the attribute list > >> > given to > >> > >> Easy to fix it to localname, but I don't want to get into ns + > >> attributes, let's leave it for ant1.7 :-) > >> ( or at least wait for the component creation to be done ). > > > > The NS standard http://www.w3.org/TR/REC-xml-names/ > > allows one to do somthing like this: > > > > <project xmlns:html='http://www.w3.org/TR/REC-html40'> > > <target name="t"> > > <echo html:class="reallyimportant">message</echo> > > </target> > > </project> > > > > of course it is up to the ant software to understand the xml file, > > but "unsupported attribute 'class'" is not a usefull error message > > in this case. > > Yes - but let's first implement namespaces on the elements. > > We can add code to ignore ( for now ) attributes that are in a different > namespace than the element - that would allow various annotations or > 3rd party tools. > > After we see how people use namespaces - we can add more features for the > attributes. > > >> Attribute + NS affects the introspection. > >> > >> > - the uris for project/target elements/attributes are not > >> > checked. > >> > >> Project and target are "owned" by ant, you can't redefine them in > >> antlibs. > > > > This is true, but using namespaces one could do: > > <project xmlns:html='http://www.w3.org/TR/REC-html40'> > > <html:target name="t"> > > <echo>hello world</echo> > > </html:target> > > </project> > > > > which is clearly wrong - but with the current code gives the > > misleading error: > > "Could not create task or type of type: target" > > There are plenty of wrong things one can do :-) Is True... > > We can fix the message to say "html:target" or use the URI, it's not > a show stopper. > > >> > - the ns standard allows different types of software processing > >> > for the different namespaces, if this is to be supported > >> > ProjectHelper2 would need to look at the uri before handing > >> > the element to the "ElementHandler" object (see my previous e-mail on > >> > the subject) > >> > >> Not sure I agree ( or understand ) this. > > > > The idea is to allow a xml ns to be used for purposes other that defining > > Unknown Elements. My example was an antdoc xml ns. > > Still don't get it. PH2 creates an object tree - and various element in the > tree can access the tree and do whatever they want. PH2 itself shouldn't > be involved in this. My idea is to get PH2 to ignore name spaces it does not understand - they then will not form part of the tree. > > >> > 3) In what ns will the introspected attributes and nested elements of > >> > the new > >> > elements reside? Some of the previous e-mails assume that they > >> > belong in the antlib's namespace - but what about datatypes that > >> > extend > >> > ant's datatypes - e.g mypath. (This is assuming that the > >> > attributes/nested elements are found by introspection - for jmx:... > >> > this may not be the case - or a different Class than > >> > IntrospectionHelper may be used). > >> > >> Those created by IntrospectionUtil - it doesn't matter, it's set by the > > > > It does matter from a build script point of view. > > > > <addon:copypath> > > <path refid="x"/> > > <remoteurl url="http://"; retry="no"/> > > </addon:copypath> > > > > is different from: > > > > <addon:copypath> > > <addon:path refid="x"/> > > <addon:remoteurl url="http://"; retry="no"/> > > </addon:copypath> > > The first case is simple - the current rules cover it. > > For the second - I don't know how could we handle it with the simple > patterns ( createPath / addPath ). > > What's your proposal ? To apply the simple patterns to the local name ? I propose using the first case. > > >> introspection rules. For the new polymorphic tasks - probably the same > >> rules of component creation as in top-level tasks. ( still not sure if > >> we agreed on how many lookup tables we'll use ) > >> > >> > 4) the proposed polymorphic element type substitution > >> > <element type="newtype"/> will need to be made ns-aware. either > >> > <newtype for-element="element"/> or the ns prefix -> ns uri > >> > mapping at the parse time when processing type="newtype" will need to > >> > be maintained. > >> > >> Probably using the prefix in newtype would be the most intuitive ( > >> <element type="antcontrib:if" /> ), but that will require some tricky > >> change in PH2 to implement. > > > > Actually I think change is easy enough. :-) > > Sorry, I don't understand exactly what behavior you want. I propose using the <element [type attribute name]="antconrib:if"/> form, where [type attribute name] is "typedef" or "ant-type" or maybe "element-type". "type" cannot be used as it is used by current tasks / datatypes. Peter.
