Return-Path: Delivered-To: apmail-avro-dev-archive@www.apache.org Received: (qmail 5548 invoked from network); 7 Dec 2010 10:59:34 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 7 Dec 2010 10:59:34 -0000 Received: (qmail 73631 invoked by uid 500); 7 Dec 2010 10:59:34 -0000 Delivered-To: apmail-avro-dev-archive@avro.apache.org Received: (qmail 73456 invoked by uid 500); 7 Dec 2010 10:59:31 -0000 Mailing-List: contact dev-help@avro.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@avro.apache.org Delivered-To: mailing list dev@avro.apache.org Received: (qmail 73448 invoked by uid 99); 7 Dec 2010 10:59:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Dec 2010 10:59:31 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [121.101.151.239] (HELO nm1.bullet.mail.in.yahoo.com) (121.101.151.239) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 07 Dec 2010 10:59:21 +0000 Received: from [121.101.151.237] by nm1.bullet.mail.in.yahoo.com with NNFMP; 07 Dec 2010 10:58:58 -0000 Received: from [121.101.151.233] by tm2.bullet.mail.in.yahoo.com with NNFMP; 07 Dec 2010 10:58:58 -0000 Received: from [127.0.0.1] by omp1002.mail.in.yahoo.com with NNFMP; 07 Dec 2010 10:58:57 -0000 X-Yahoo-Newman-Id: 295312.95454.bm@omp1002.mail.in.yahoo.com Received: (qmail 41326 invoked from network); 7 Dec 2010 10:58:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=Zonu6dh21+4u8E20SB+6QTJFC6c7wrOpu39nnbPG8N71nYP7+xCb7kzxpTDUFQpOJY/tVAdYH/azS7jGfiM4mjPe0jGc3BtJQUpPUpKXboOHdhzApbOld0R95Ai8Bf4TAOPONAEYH1CtMUPGad2Mzi2f3P36bDoa66aObxC/2hE= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1291719538; bh=QU5+g+X1Jm4nWLsAUbnW6MW7dvQ49rsf7cPgPBfPY6Q=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=ZON/KkqYpNfExwWokrmty7lKl+oJyaqaR6DGRCy/vSyLJwwQ0XypSt02IqMWagXIidk5ptGoFQQopi4M/UvK8Tf12z2BCvDZ8w3gehME7qu1RGvpQE0kLwMaM5M5/u5gLde0Jcxkm5JOcUgPRyPq8NLY9iMuKyeo9aH7anJnUdc= Received: from tailheavylx (thiru_mg@203.83.248.37 with login) by smtp107.mail.in.yahoo.com with SMTP; 07 Dec 2010 16:28:58 +0530 IST X-Yahoo-SMTP: y0avFBCswBBsPm7UbvggH0deto8q X-YMail-OSG: SxpU8QkVM1mZKXBtrwBnI7VZDxZkOs0vr.yBiSsDQJ83H9e qagw.Z6tcRV7rtBEzq6PSsRA5x3xVD0wOYBNAnEI5PW2yQLC.fqj9ZmLDfpa lVYtNb2xpjtSPzri2AQcZSyEmyChAPzbd17JTTQaTuTVet6KeeG7xL2YaPAO pwTbrYGsOO6JWtCkwRyhI2LL25buxkVDVeYCQGtwYcRq3SG5ZCIwOB_Bi0J6 m9boSRlzkrvIE25OPRVwaDmmnwagX X-Yahoo-Newman-Property: ymail-3 From: "Thiruvalluvan M. G." To: Subject: Union with a single branch Date: Tue, 7 Dec 2010 16:28:57 +0530 Message-ID: <001b01cb95fd$bfb97ce0$3f2c76a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuV/b45PICvn+vbR9WxHZCLrhtpRw== Content-Language: en-us X-Virus-Checked: Checked by ClamAV on apache.org The Java implementation allows unions with just one branch. But C++ implementation doesn't. The spec is silent in this respect. Is there a need for single-branch unions? There could be an argument that single-branch unions can be used for future extensions. But I don't think it is needed because our resolution spec allows matching standalone entities with unions as long as the entity's type is one of the branches in the union. Another argument could be that data written using single-branch union can be read by multi-branch union without using schema resolution. But we do not want to encourage such usage. If the schemas for reader and writer are different (in whatever way) we want people to use schema resolution. The only valid argument I could think of is that someone may already be using single-branch unions. Tightening the spec will break their code. Tightening spec will also means that all language implementations should fix the problem, if they haven't already. In any case we need to make the implementations consistent and make the specification explicit in this regard. Any thoughts? Thanks Thiru