ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gus Heck <...@speakeasy.net>
Subject Re: a comment about xml namespace
Date Fri, 02 Jan 2004 18:45:24 GMT
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 xml. Since it is unique it could be mumblyfoo://barbazbam 
and still work (I think). This would also apply to tasks introduced with 
<taskdef/>.

2. The name space URIs that antlibs declare to identify their
components. Each of these 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 to retain back 
compatability, but just as with classpaths it might matter what order 
the antlibs were in if there were conflicting elements. User specified 
antlibs would need to follow the ones we distributed in the search 
order. 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/tasks/optional/unix#

and the individual tasks could be identified as the fragment parts:

   antlib://ant.apache.org/antlibs/tasks/optional/unix/#symlink
   antlib://ant.apache.org/antlibs/tasks/optional/unix/#chgrp

This gives each task a URI of it's own, and would potentially allow us, 
custom task authors, or anlib authors to provide RDF metadata for tasks 
as well as RDF metadata in the build file. I'm not sure how such data 
would get used, but I'm sure someone will think of a use. Perhaps there 
will be an ontology to describe tasks to IDE's so that IDE's can attempt 
to integrate antlibs not known about by the IDE authors? like maybe this 
triple for a dependancyreasoner task

antlib://example.org/antlibs/#dependancyreasoner
http://ant.apache.org/ontologies/ant-ide-integration#contentType
http://www.w3.org/2002/07/owl#

The IDE could then ask itself (or some external entity) if it knew 
anything about OWL, and perhaps discover a means of validating the 
content as proper OWL (a web service? something like w3c's 
html-validator? download a lib from the ide vendor?) or warn the user 
that it doesn't know how to validate OWL. Ok so I can think of one... 
Imagine builds that think for themselves... scary :)

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


Mime
View raw message