Return-Path: Delivered-To: apmail-xerces-j-dev-archive@www.apache.org Received: (qmail 33895 invoked from network); 11 Aug 2009 04:12:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Aug 2009 04:12:15 -0000 Received: (qmail 36680 invoked by uid 500); 11 Aug 2009 04:12:21 -0000 Delivered-To: apmail-xerces-j-dev-archive@xerces.apache.org Received: (qmail 36600 invoked by uid 500); 11 Aug 2009 04:12:21 -0000 Mailing-List: contact j-dev-help@xerces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: j-dev@xerces.apache.org Delivered-To: mailing list j-dev@xerces.apache.org Received: (qmail 36592 invoked by uid 99); 11 Aug 2009 04:12:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Aug 2009 04:12:21 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of hiranya911@gmail.com designates 209.85.219.217 as permitted sender) Received: from [209.85.219.217] (HELO mail-ew0-f217.google.com) (209.85.219.217) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Aug 2009 04:12:12 +0000 Received: by ewy17 with SMTP id 17so3610402ewy.26 for ; Mon, 10 Aug 2009 21:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=lpcVZnyXJq9h4OmJ2fzAg60800OnpDrVzI3GlaWZx/8=; b=GleHPhYUYOaOmn4vsLklXIycLrA1mKkwPK4vTtzDC6LswnnigCQPwRRX95rit0lDcw vmg9RtvJngxRHpIpnqmgWSf+Tninwiz+FcvW0zZVd2MWwYmpnvr3L5wUYqXTx47PMwIG 7qLwohuyAGOywyAvD7LPpEmdmQR1MHeCikMGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rF9pyM0L7NI5DpcHL2X2xm2uzKm87AODz2s39QpLtykv/iJXNcM1UmaORMXGk3AzTl a2znCPZKB5N8D5sPSoB8pHZGwdy8QqLll5l8lpCWlX/LmAaGAy9iTb3SXSljrj3e3OVe DQuDC6a/gQPvYT7ioCdW0Zs5VDlimqKEt69NQ= MIME-Version: 1.0 Received: by 10.210.28.4 with SMTP id b4mr5872542ebb.47.1249963910851; Mon, 10 Aug 2009 21:11:50 -0700 (PDT) Date: Tue, 11 Aug 2009 09:41:50 +0530 Message-ID: <558af1840908102111v27826682p41b62642089e48da@mail.gmail.com> Subject: Changing the CTA API to Support Arbitrary Inputs From: Hiranya Jayathilaka To: j-dev@xerces.apache.org Content-Type: multipart/alternative; boundary=0015174c1aace36ebe0470d5e64b X-Virus-Checked: Checked by ClamAV on apache.org --0015174c1aace36ebe0470d5e64b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Devs, The XML schema 1.1 conditional type assignment (CTA) API we currently have restricts passing additional information to the test expression evaluator. We can only pass the attributes information as of now. In an offlist discussion, Khaled pointed out the benefits we can gain by changing the current API to support passing of arbitrary data (for example through a map) so that we don't have to change the API everytime when a requirement comes up to pass a new data item to the XPath evaluator. FYI with Mukul working on inheritable attributes feature such a requirement has already shown up :) So what do you think about changing the existing API to accept a map of objects instead of a fixed number of arguments? Changing the Test class which is the high level entry point to XPath evaluator is easy. Should we also change the low level classes which are responsible for processing the actual XPath? Thanks, Hiranya -- Hiranya Jayathilaka Software Engineer; WSO2 Inc.; http://wso2.org E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com --0015174c1aace36ebe0470d5e64b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Devs,

The XML schema 1.1 conditional type assignment (CTA) API we= currently have restricts passing additional information to the test expres= sion evaluator. We can only pass the attributes information as of now. In a= n offlist discussion, Khaled pointed out the benefits we can gain by changi= ng the current API to support passing of arbitrary data (for example throug= h a map) so that we don't have to change the API everytime when a requi= rement comes up to pass a new data item to the XPath evaluator. FYI with Mu= kul working on inheritable attributes feature such a requirement has alread= y shown up :)

So what do you think about changing the existing API to accept a map of= objects instead of a fixed number of arguments? Changing the Test class wh= ich is the high level entry point to XPath evaluator is easy. Should we als= o change the low level classes which are responsible for processing the act= ual XPath?

Thanks,
Hiranya

--
Hiranya Jayathilaka
S= oftware Engineer;
WSO2 Inc.; =A0http://wso2.= org
E-mail: hiranya@wso2.com= ; =A0Mobile: +94 77 633 3491
Blog: http://techfeast-hi= ranya.blogspot.com
--0015174c1aace36ebe0470d5e64b--