Return-Path: 
 <user-return-59512-apmail-ant-user-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-user-archive@www.apache.org
Received: (qmail 48755 invoked from network); 24 Jan 2007 05:24:02 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 24 Jan 2007 05:24:02 -0000
Received: (qmail 64919 invoked by uid 500); 24 Jan 2007 05:24:04 -0000
Delivered-To: apmail-ant-user-archive@ant.apache.org
Received: (qmail 64877 invoked by uid 500); 24 Jan 2007 05:24:04 -0000
Mailing-List: contact user-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:user-unsubscribe@ant.apache.org>
List-Help: <mailto:user-help@ant.apache.org>
List-Post: <mailto:user@ant.apache.org>
List-Id: "Ant Users List" <user.ant.apache.org>
Reply-To: "Ant Users List" <user@ant.apache.org>
Delivered-To: mailing list user@ant.apache.org
Received: (qmail 64865 invoked by uid 99); 24 Jan 2007 05:24:04 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Jan 2007 21:24:04 -0800
X-ASF-Spam-Status: No, hits=1.4 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: 204.127.225.92 is neither permitted
 nor denied by domain of hoju@visi.com)
Received: from [204.127.225.92] (HELO alnrmhc12.comcast.net) (204.127.225.92)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Jan 2007 21:23:54 -0800
Received: from nicki.visi.com
 (c-24-131-157-61.hsd1.nh.comcast.net[24.131.157.61])
          by comcast.net (alnrmhc12) with SMTP
          id <20070124052332b1200qcejoe>; Wed, 24 Jan 2007 05:23:32 +0000
Message-Id: <7.0.1.0.0.20070123231917.0540cf20@visi.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Tue, 23 Jan 2007 23:23:40 -0600
To: "Ant Users List" <user@ant.apache.org>
From: Jacob Kjome <hoju@visi.com>
Subject: Re: <xmlproperty> intra-element attribute property resolution
    issue
In-Reply-To: <45B5F4B3.2080001@apache.org>
References: <1168902419.45ac091403f69@my.visi.com>
 <45ACB628.8020204@apache.org>
 <1168990525.45ad613d9dd0b@my.visi.com>
 <45ADF7D4.8020601@apache.org>
 <1169048903.45ae4547c98bf@my.visi.com>
 <7.0.1.0.0.20070117235524.050f00d8@visi.com>
 <45AF65B6.4070204@apache.org>
 <7.0.1.0.0.20070118214102.050f01a0@visi.com>
 <45B4A1CD.6010407@apache.org>
 <45B4A596.7060307@oopsconsultancy.com>
 <B9550324A189244E9C8922F053FF990501FBBBC2@ex01silver.silverlink.com>
 <7.0.1.0.0.20070122233857.058e28a8@visi.com>
 <45B5F4B3.2080001@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Relayed-By: GPGrelay Version 0.959 (Win32)
X-Virus-Checked: Checked by ClamAV on apache.org


I see your point.  Even if the functionality was something you would 
support, I'm not sure there's anyone willing to put in the time to 
figure it out.  But you never know.  Like I said before, it could be 
an option.  So, if someone actually did the work, and it passed 
rigorous testing, the functionality could be disabled by default and 
only enabled explicitly, just like some of the other options of XMLProperty.

Anyway, it was a good discussion and helped fetter out bugs in 
AntUnit.  BTW, any progress on that?

Jake

At 05:42 AM 1/23/2007, you wrote:
 >Jacob Kjome wrote:
 >> At 05:22 PM 1/22/2007, you wrote:
 >
 >>  >
 >>  >It's not a solvable problem. How do you resolve this:
 >>  >
 >>  ><element a="${element.b}" b="${element.a}"/>
 >>  >
 >>
 >> I would argue that's not a relevant problem.  First of all, no one would
 >> write that because it is meaningless.  Secondly, it might go like this...
 >>
 >> 1.  parse 'a'
 >> 2.  can't resolve 'a' value.  Defer it for later processing to see if
 >> it's resolvable after other attributes are processed
 >> 3.  parse 'b'
 >> 4.  'a' is available, but I've recorded that it's an unresolved value,
 >> so defer until 'a' is resolved
 >> 5.  all attributes have been processed, so let's go back and try to
 >> resolve unresolved values
 >> 6.  attempt 'a' value property resolution: 'b' exists, but 'b' refers
 >> back to 'a'.  Detected circular reference.  Resolve 'a' as literal
 >> unresolved value of 'b' and vice-versa.
 >>
 >> Now lets try something realistic...
 >>
 >> <element a="${element.b} bar" b="foo"/>
 >>
 >> 1.  parse 'a'
 >> 2.  can't resolve 'a' value.  Defer it for later processing to see if
 >> it's resolvable after other attributes are processed
 >> 3.  parse 'b'
 >> 4.  all attributes have been processed, so let's go back and try to
 >> resolve unresolved values
 >> 5.  attempt 'a' value property resolution: 'b' exists so resolve
 >> property.  Final value "foo bar"
 >>
 >>
 >> While the code might be a little difficult/complex, I don't think it is
 >> properly characterized as "not a solvable problem".
 >
 >Oh, I agree, it's not unsolvable, is just hard work.
 >
 >There's two algorithms for resolving such things
 >
 >Iteration
 >=====
 >-walk the graph (and it is now a graph, not a tree)
 >-if all references are resolved, exit w/ success
 >-if something can be resolved, resolve it and update that node, marking
 >the graph as changed
 >-complete doing so until the graph is finished
 >-if you do walk of the graph and make no changes, yet the graph is
 >unresolved, you have an unresolvable graph. fail with an error.
 >
 >this can be quite inefficient as you have to walk the graph [an O(n)
 >operation] for every iteration. In the worst case, you'd only resolve
 >one thing per iteration, so its an O(n*u) process; where n:=number of
 >elements in the tree, u:=number of unresolved. Best case: O(n)
 >-everything resolves in one run. It can take a lot of iterations to
 >decide that something doesnt resolve.
 >
 >directed
 >=====
 >-pick an unresolved node
 >-push its xpath on the stack
 >-locate its references (i.e. walk the tree to them)
 >-recursively resolve them.
 >
 >The cost of this is one is trickier to guess. its an O(n) walk of the
 >graph to find unresolved nodes, followed by O(u) resolutions.
 >
 >test cases would include chaining
 ><a a1="${b.a2}" />
 ><b a2="${c.a2}" />
 ><c a2="${a.a1}" />
 >
 >and double expansion. This one is probably trickiest, You have to deal
 >with things like
 ><a a1="${b.a2}:${c.a2}" />
 ><b a2="${c.a2}" />
 ><c a2="success" />
 >
 >where the result is al.a1=> success:success
 >
 >And reject stuff like
 >
 ><a a1="${b.a2}:${c.a2}" />
 ><b a2="${c.a2}" />
 ><c a2="${b.a2}" />
 >
 >Its not clear this algorithm is cheaper; you end up walking the graph a
 >lot either way. Where it is efficient is if you dont want to resolve the
 >entire tree, but only a subset of it, and the rest is just abstract
 >stuff you dont need to instantiate. The other algorithm is still kind of
 >handy to have around to verify that you are resolving everything, and
 >that the results are the same.
 >
 >You need a big number of test cases to resolve all this stuff, esp. if
 >you allow more complex references (like .. and other bits of xpath) or
 >lazy references whose resolution can be deferred until runtime, at which
 >point the graph and its xmlns nodes have moved around a fair bit. We
 >ended up writing our own test runner that would take input and output
 >elements and check the output matched the input, as this was the only
 >way to do the large number of tests required:
 >
 >Here, for example, is one to check that qnames are expanded in the
 >original xmlns context:
 >http://deployment.cvs.sourceforge.net/deployment/deployment/test/org/g
 >gf/cddlm/files/cdl/valid/set_02_references/cddlm-cdl-2005-02-0016.xml?
 >view=markup
 >
 >I then had to hack  junit so that it would run these files from a
 >manifest, working with the three different java implementations that
 >were done
 >http://deployment.cvs.sourceforge.net/deployment/deployment/src/java/o
 >rg/ggf/cddlm/cdl/test/
 >Then there was the XSL transforms to take the test cases and produce
 >HTML docs that can be submitted as part of the compliance results for
 >the standard.
 >
 >So no, not impossible. Just not, something I feel that XmlProperty needs.
 >
 >-steve
 >
 >---------------------------------------------------------------------
 >To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
 >For additional commands, e-mail: user-help@ant.apache.org
 >
 >
 > 


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