Mailing-List: contact dev-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
MIME-Version: 1.0
In-Reply-To: <53EC4E26-4E2E-4FEC-A6E4-18418D170A52@gmail.com>
References: 
 <DM2PR0601MB1104ECCDA3B9627452488D91FA3D0@DM2PR0601MB1104.namprd06.prod.outlook.com>
	<CACAwhF=nWDv0UZwmSWfJa0cRAqyyx+aC230pJmS2a=n12up37w@mail.gmail.com>
	<FCF963F2-2D10-4033-90D0-8F768659C411@hydromatic.net>
	<CANpYTofp9XtrhsFMOfP3ChQ2L_5TOmiW+j30stAkVYWhzkzF3g@mail.gmail.com>
	<53EC4E26-4E2E-4FEC-A6E4-18418D170A52@gmail.com>
Date: Sat, 17 Oct 2015 13:51:15 -0700
Message-ID: 
 <CAPSgeERzti_1J1cKdECybF1sS2Xs00+Di8Ex9Z7meAzu-kDPMA@mail.gmail.com>
Subject: Re: Apache Drill
From: Julian Hyde <jhyde@apache.org>
To: dev@drill.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes, frankly, performance is a concern. But there are also many
concerns about to fit a deep XML document into Drill's very
json-centric model. Building a good XML adapter is a very big task. My
hunch is that we should not let the perfect be the enemy of the good.
Build a version 1 XML adapter based on an XML-to-JSON converter and it
will give us plenty of ideas for what the "perfect" adapter in version
2 should look like.

On Sat, Oct 17, 2015 at 1:43 PM, Matt Burgess <mattyb149@gmail.com> wrote:
> If the converter is clean and performant then I'm sure the community (inc=
luding me) is interested :)
>
> However I wonder if Drill can afford to add a translation layer between d=
ata formats, could we be better served with similar parsing in Drill for XM=
L as we do for JSON, or can it be pushed down far enough (to the parser) to=
 not make a noticeable difference (which is what I think Julian is implying=
)?
>
> Sent from my iPhone
>
>> On Oct 17, 2015, at 1:41 PM, Magnus Pierre <mpierre@maprtech.com> wrote:
>>
>> Hello,
>>
>> Just wrote a simple sax implementation that converts xml to json and tha=
t
>> is able to deal with decently complex xml's, that I currently use in Sto=
rm.
>> Takes attributes, and everything.
>>
>> I can share it with the community if interesting.
>>
>> /Magnus
>> Den 17 okt 2015 7:02 em skrev "Julian Hyde" <julian@hydromatic.net>:
>>
>>> Seems to me the biggest problem is to make drill understand the nested
>>> structure of an xml document. That work has been done for json, so let'=
s
>>> build on it. Suppose there was a translator that converted xml to json
>>> (adding attributes for things that json lacks, such as namespaces, text=
,
>>> element tags). Drill knows how to handle json, even if it is a bit verb=
ose.
>>> The translator could be applied on the fly.
>>>
>>> Julian
>>>
>>>
>>>
>>> Sent from my iPad
>>>>> On Oct 16, 2015, at 2:31 PM, Stef=C3=A1n Baxter <stefan@activitystrea=
m.com>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> It's not possible but there has been some talk here about supporting i=
t.
>>>> If I remember correctly it's rather complicated and not really feasibl=
e.
>>>> (I'm just a newbie so don't take my words for it)
>>>>
>>>>
>>>> Regards,
>>>> -Stefan
>>>>
>>>> On Fri, Oct 16, 2015 at 8:54 PM, Daniel Ajo <Daniel.Ajo@abarcahealth.c=
om
>>>>
>>>> wrote:
>>>>
>>>>> Hey there,
>>>>>
>>>>> I was wondering if it is possible to query XML files using Apache Dri=
ll?
>>>>>
>>>>> I see there are several formats, and maybe it would work using an xpa=
th
>>>>> query of some sorts, but just wondering if it would work to directly
>>> query
>>>>> it using some sort of plug-in.
>>>>>
>>>>> Well, let me know,
>>>>>
>>>>> Daniel Ajo
>>>>> *********************************************************
>>> CONFIDENTIALITY
>>>>> NOTE: This electronic transmission contains information belonging to
>>> Abarca
>>>>> Health LLC, which is confidential or legally privileged. If you are n=
ot
>>> the
>>>>> intended recipient, please immediately advise the sender by reply
>>> e-mail or
>>>>> telephone that this message has been inadvertently transmitted to you
>>> and
>>>>> delete this e-mail from your system. If you have received this
>>> transmission
>>>>> in error, you are hereby notified that any disclosure, copying,
>>>>> distribution or the taking of any action in reliance on the contents =
of
>>> the
>>>>> information is strictly prohibited.
>>>