ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gus Heck <gus-ant...@cognition.olin.edu>
Subject Re: a comment about xml namespace
Date Fri, 02 Jan 2004 18:52:47 GMT
This seems to be an incomplete version of what I wrote and does not 
match what I find in my sent folder. I will try again and hope I don't 
spam you all too much. my mail client seems to be acting funny. Appologies.

-Gus

Gus Heck wrote:

> I have only followed this discussion peripherally at best, and I know 
> it has been going on for a while, so I am almost certainly be missing 
> information from previous posts, but here's what strikes me as 
> potentially reasonable... and thus represents my initial expectations 
> of what I will find when I do get around to exploring antlibs. It 
> seems to me that in an ant file of the future one might find:
>
> 1. There should be a name space URI that ant uses to identify it's 
> internal core components... the things we distribute that are not in 
> antlibs. This should be the default namespace for any element that 
> does not have a defined namespace. This could have a antcore:// or 
> just ant:// scheme part for recognizability, or be a http:// schemed 
> URI with the idea that it better identifies the source of the program 
> intended to process the
>
> 2. The name space URI that a given antlib declares to identify it's 
> components and is associated with user specified prefix.We probably 
> should require these URI's to use the antlib:// scheme so that they 
> are easily identified as xml elements that we do need to pay attention 
> to. Elements without a prefix that were not matched against the core 
> could then be searched for among the antlibs, but just as with 
> classpaths it might matter what order the antlibs were in if there 
> were conflicting elements. This is potentially hairy, but if it is to 
> be possible for people to write and distribute thier own antlibs, then 
> this is going to crop up no matter what we do. The URI should be 
> defined IN the antlib, and might be associated with it's prefix 
> directly in the ant xml (causing the main engine to look for an antlib 
> in default and declared locations that declares itself as to have that 
> URI and error out if an antlib:// scheme uri does not match an 
> available antlib) or if the user wants to use only default name spaces 
> and let ant figure out what lib to use <antlib 
> lib="foo/bar-antlib.jar"/> or somesuch to tell ant to look there too 
> for otherwise unrecognized elements.
>
> It would seem reasonable that antlibs maintained by apache ant would 
> have a uri like:
>
>  antlib://ant.apache.org/antlibs/optional/unix
>
> and the individual tasks could be identified (though I am not sure 
> what use it is for ant, it would be genrally consistant with RDF and 
> potentially allow us, custom task authors, or anlib authors to provide 
> RDF metadata for tasks) as the fragment parts:
>
>  antlib://ant.apache.org/antlibs/optional/unix/#symlink
>  antlib://ant.apache.org/antlibs/optional/unix/#chgrp
>
> antcontrib might have an antlib that was specified as......
>
>  antlib://ant-contrib.sourceforge.net
>
> which of course has.....
>
>  antlib://ant-contrib.sourceforge.net#foreach
>
> 3. Other name space URI's associated with prefixes but not associated 
> with antlibs. If it isn't in the core and it is not an antlib, just 
> ignore it. If it is contained within a task, it should be available to 
> the task If the task requires (for example) valid RDF subelements, it 
> should look for elements that are associated with the rdf 
> namespace(s), and ignore others. Tasks requiring content that uses an 
> external name space should have a way of communicating this namespace 
> to a list of recognized name spaces.
>
> Then one could run ant in 1 of 3 name space modes... -nsFail -nsWarn 
> -nsIgnore. I don't see typos as a big problem if things were done this 
> way, because URI's would be pulled from the libs and prefix typos can 
> be identified with warn or fail mode. If you typo from one prefix into 
> another... I don't think we can ever fix that problem. If you 
> construct your build in a way that regularly uses outside name spaces 
> without a task to register them as recognized, the <?ant-ignore 
> uri=""?> seems like a good way to still allow -nsFail to be useful, 
> but if you do
>
>  <?ant-ignore uri="http://www.w3.org/1999/02/22-rdf-syntax-ns#" ?>
>
> then you can't have a task that uses RDF subelements (unless there is 
> a way for tasks to un-ignore name spaces, or ignore without throwing 
> away).
>
> How far are my expectations from what is actually in place? What are 
> the flaws in my expectations (I am sure there will be plenty :) )?
>
> -Gus
>
>
> Jose Alberto Fernandez wrote:
>
>>> From: Jim Fuller [mailto:jim.fuller@ruminate.co.uk]
>>> I like the idea that Ant may understand what to do with other 
>>> external namespaces like such as proposed with the html: example. 
>>> And generally agree with how it is proposed how Ant deals with 
>>> namespaces it 'knows' about.
>>>
>>>   
>>
>>
>> I am going to become picky here because I think it is important
>> to understand the small details in this conversation.
>>
>> There are several ways to understand what it means for ANT to "know 
>> about" a namespace:
>>
>> 1) ANT knows about any namespace declaration that there is in your 
>> buildfile. This may not seem too interesting.
>>
>> 2) ANT gives a special meaning at namespaces declared using
>> "antlib:..." URLs. Which it uses to automatically load libraries.
>>
>> 3) ANT knows about tasks and types declared inside some URI
>> (any URI) using <typedef uri="..."> or <taskdef uri="...">.
>>
>> Given the above, what do you mean by namespaces "ANT does not know"
>> about? Given (3) ANT cannot just ignore it, since it may be a typo of 
>> some sort. There is not such a thing as an ignorable
>> namespace (unless we define a way to tell to ANT to ignore it).
>>
>>  
>>
>>> The main point of my example is that instead of continually 
>>> expanding the Ant schema to accommodate other meta data that is 
>>> non-build specific, to allow non-ant specific namespaced 
>>> elements/attributes (meta
>>> data) to be allowed inside an ant build document.
>>>
>>> Perhaps these namespaces can bind to another java class ( as with 
>>> binding java functions in XSLT ) which ultimately determine how they 
>>> are processed within an Ant context...perhaps not.... though I can 
>>> see this being useful in consistently bringing in external scripting 
>>> languages to Ant ( though this is not critical to my argument ).
>>>   
>>
>>
>> I see two ways here:
>> 1) The already mentioned task Or type
>> <comment> or better <ignore> in which you may be able to include any

>> XML you like. And hence keep anotations away boxed-off.
>>
>>  <ant:ignore>
>>    <rdf:x xmlns:rdf="....">...</rdf:x>
>>  </ant:ignore>
>>
>> 2) Alternatively, one could think of using XML processing-instructions
>> to tell ANT that some particular namespace should be ignored by ANT.
>>
>>  <?ant-ignore uri="...."?>
>>  <rdf:x xmlns:rdf="....">...</rdf:x>
>>
>> The different approaches may produce quite different functionality,
>> while
>> in (1) all foreign URIs segregated appart from the rest of the ANT
>> lingo, on (2) we could actually intermix them freely:
>>
>>  <?ant-ignore uri="...."?>
>>  <project ... xmlns:rdf="....">
>>    <rdf:x >...</rdf:x>
>>    <target name="xyz" rdf:description="This is my description">
>>      <copy ....>
>>        <rdf:comment>This is a comment inside the code</rdf:comment>
>>        <fileset ..../>
>>      </copy>
>>    </target>
>>  </project>
>>
>> Which would produce a very powerful intermingling capability,
>> but it may be too powerful (i.e., too confising for the uninitiated).
>>
>> (1) should be trivial to do in 1.7, (2) would require changes
>> in ProjectHelper to implement the processing-instruction.
>>
>>  
>>
>>> A few use cases;
>>>
>>> Eventually perhaps there will be a standard method of annotating xml 
>>> documents, I use the RDF/Dublin core initiative but perhaps someone 
>>> would want to use an XHTML custom module embedded in Ant 
>>> <description/> elements. There is a real need for versioning Ant xml 
>>> files
>>>
>>>   
>>
>> Fine.
>>
>>  
>>
>>> Perhaps Ant will be required during the course of a build sensitive 
>>> pieces of information, why not intermix XML Encryption / Signature 
>>> which could be expanded when/if securely during the build process ? 
>>> This could range to simple username/passwords to embedding 
>>> public/private keys etc.... .
>>>
>>>   
>>
>>
>> This I do not buy (yet). Certaintly you can resolve this by having
>> the sensitive info in an encripted file and having a task
>> that loads the information during the execution of the build.
>> You can write the task to use whatever technology you want it to use.
>>
>>  
>>
>>> It's in this way that we can provide a 'dense' xml document packed 
>>> with all the information for a build, at the same time leveraging 
>>> external xml vocabularies instead of cooking their own variant every 
>>> time the need pops up. At some point we shall see the boundaries 
>>> between file-based documents blurring with the usage of storing such 
>>> XML in XML DB repositories. XML namespaces will become the true 
>>> boundary between xml vocabularies instead of a physical boundary 
>>> imposed by our current usage of files and directories. Perhaps this 
>>> is something to think about for Ant 2.0.
>>>
>>>   
>>
>>
>> I think an aproach like (2) could give the correct balance
>> on your direction.
>>
>>  
>>
>>> Cheers, jim
>>>
>>> -----Original Message-----
>>> From: Peter Reilly [mailto:peter.reilly@corvil.com] Sent: 22 
>>> December 2003 13:53
>>> To: Ant Developers List
>>> Subject: Re: a comment about xml namespace
>>>
>>> This is what I (think I) originally proposed, but did
>>> not articulate it correctly.
>>>
>>> http://marc.theaimsgroup.com/?l=ant-dev&m=105240500519029&w=2
>>>
>>> Peter
>>> Jim Fuller wrote:
>>>
>>>   
>>>
>>>> Consider the following;
>>>>
>>>> <?xml version="1.0"?>
>>>> <project name="Demonstrate namespace options" default="demo">
>>>>     <RDF:RDF xmlns:RDF="http://www.w3c.org/RDF/"
>>>> xmlns:DC="http://purl.org/RDF/DC/">
>>>>     <RDF:Description 
>>>> RDF:HREF="http://purl.org/metadata/dublin_core_elements"
>>>>         DC:Title="namespace build"    
>>>>         DC:Creator="Jim Fuller"
>>>>         DC:Subject="xml namespaces"         
>>>> DC:Description="Contains Ant artifacts for building"         
>>>> DC:Publisher="Webcomposite s.r.o."         DC:Format="text/html" 
>>>>         DC:Type="Technical Report"         DC:Language="en"         
>>>> DC:Date="12/22/2003"/>
>>>>     </RDF:RDF>
>>>>     
>>>>     <description>intermixing of namespaces</description>
>>>>     
>>>>     <target name="demo" description="build entry point">
>>>>         <echo message="successful build"/>
>>>>     </target>
>>>> </project>
>>>>
>>>> XML Namespaces was initially created to avoid collision within
>>>>     
>>>
>>> documents
>>>   
>>>
>>>> that have multiple xml vocabularies.
>>>>
>>>> Ant seems to assume by default that all namespaces have     
>>>
>>> something to do   
>>>
>>>> with build processing...is their any convention planned for     
>>>
>>> having Ant   
>>>
>>>> ignore specific namespace elements...or more usefully all 
>>>> namespaces that have no Ant processing associated with it ?
>>>>
>>>> For instance, the above example maybe generated by a     
>>>
>>> sophisticated XML   
>>>
>>>> editor that uses Dublin Core and RDF as a method of tracking versions
>>>>     
>>>
>>> of
>>>   
>>>
>>>> the build.xml file. This is a simple use case, there are other more 
>>>> important use cases involving xml db repositories.
>>>>
>>>> Regards, Jim Fuller
>>>>
>>>>
>>>> -------------------------------------------------------------
>>>>     
>>>
>>> ----------
>>> -
>>>   
>>>
>>>> ----Jim Fuller Technical Architect  WebComposite s.r.o. 
>>>> jim.fuller@ruminate.co.uk/http://www.ruminate.co.uk
>>>> Co-Author ISBN 1861007213 Professional PHP4 XML
>>>> Co-Author ISBN 1861008074 Professional PHP Web Services Technical 
>>>> Reviewer 'Beginning XSLT', 'Beginning Databases', 'XML 
>>>> Antipatterns' and various other xml / web service books
>>>> -------------------------------------------------------------
>>>>     
>>>
>>> ----------
>>> -
>>>   
>>>
>>>> ----
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>
>>>
>>>   
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>  
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message