XOM API for Processing XML with Java

["Trimmer, Todd" <todd.trimmer AT trizetto.com>]

Let's say three different systems use XML in wildly different ways:


System 1 often concentrates on a large group of sibling elements at one
time. It does sequential reads and random access reads by position.
ArrayLists behoove it.

System 2 does a lot of adds of new Elements and removes of old Elements
under the same parent. LinkedLists behoove it.

System 3 does a lot or random access by tag name and/or attribute value (key
lookup). Maps behoove it.


What if there was an OM that let you at parse time request what type of
storage the Nodes will be placed under? The same operations would exist
under each of them. You can still use solid classes; no need for interfaces.
What would the ramifications be? Would the Documents become interoperable?
Would they fall under the same serialization curses that DOM did?

I know playing with the underlying storage is not a goal of XOM. But I was
trying to construct a reason why a vendor would not want to stick to
consistently using the same XML API everywhere. The vendor might need some
more optimization in critical areas. This puts a huge strain on the
programmers working for said vendor.

I was wondering if it was even possible for an OM to try to accomodate the
three cited needs above and yet still provide one clear public API all the
time -- transparently.



Todd Trimmer
>From CustomPrintGoods AT netscape.net  Thu Apr 10 14:31:50 2003
Return-Path: <CustomPrintGoods AT netscape.net>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from sbs2000.ywt.com.tw (61-221-176-153.HINET-IP.hinet.net
        [61.221.176.153])
        by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 833922001D
        for <xom-interest AT lists.ibiblio.org>;
        Thu, 10 Apr 2003 14:31:48 -0400 (EDT)
Received: from smtp0211.mail.yahoo.com ([66.170.166.245]) by
        sbs2000.ywt.com.tw with Microsoft SMTPSVC(5.0.2195.5329);
        Fri, 11 Apr 2003 02:30:28 +0800
Date: Thu, 10 Apr 2003 18:31:29 GMT
From: CustomPrintGoods AT netscape.net
X-Priority: 3
To: xom-interest AT lists.ibiblio.org
Mime-Version: 1.0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: base64
Message-ID: <SBS2000pMgUUDig6opN0000b642 AT sbs2000.ywt.com.tw>
X-OriginalArrivalTime: 10 Apr 2003 18:30:29.0437 (UTC)
        FILETIME=[434DBED0:01C2FF8F]
Subject: [XOM-interest] 
        Custom Printed T-Shirts $2.10 - Embroidered Golf Shirts $11.95
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2003 18:31:50 -0000

PGh0bWw+DQoNCjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPg0KDQo8cCBhbGlnbj0iY2VudGVyIj48
Zm9udCBzaXplPSIzIiBmYWNlPSJWZXJkYW5hIj48c3Ryb25nPllPVVIgTE9HTzwvc3Ryb25nPg0K
YWZmb3JkYWJseSBwcmludGVkIG9uIHF1YWxpdHkgSGFuZXMgR29sZiBTaGlydHMgJmFtcDsgVGVl
IFNoaXJ0czwvZm9udD48L3A+DQoNCjxkaXYgYWxpZ249ImNlbnRlciI+PGNlbnRlcj4NCg0KPHRh
YmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjQiIGNlbGxzcGFjaW5nPSIwIj4NCiAgICA8dHI+
DQogICAgICAgIDx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249InRvcCIgYmdjb2xvcj0iI0ZGRkYw
MCI+PGZvbnQNCiAgICAgICAgY29sb3I9IiMwMDAwMDAiIHNpemU9IjUiIGZhY2U9IlZlcmRhbmEi
PjxzdHJvbmc+R29sZjwvc3Ryb25nPjwvZm9udD48Zm9udA0KICAgICAgICBjb2xvcj0iIzAwRkYw
MCIgc2l6ZT0iNSIgZmFjZT0iVmVyZGFuYSI+PHN0cm9uZz4gPC9zdHJvbmc+PC9mb250Pjxmb250
DQogICAgICAgIGNvbG9yPSIjMDAwMDAwIiBzaXplPSI1IiBmYWNlPSJWZXJkYW5hIj48c3Ryb25n
PlNoaXJ0czwvc3Ryb25nPjwvZm9udD48L3RkPg0KICAgICAgICA8dGQgYWxpZ249ImNlbnRlciIg
dmFsaWduPSJ0b3AiIGJnY29sb3I9IiMwMEZGMDAiPjxmb250DQogICAgICAgIGNvbG9yPSIjMDAw
MDAwIiBzaXplPSI1IiBmYWNlPSJWZXJkYW5hIj48c3Ryb25nPlQtU2hpcnRzPC9zdHJvbmc+PC9m
b250PjwvdGQ+DQogICAgPC90cj4NCiAgICA8dHI+DQoNCiAgICAgICAgPHRkIGFsaWduPSJjZW50
ZXIiIHZhbGlnbj0idG9wIiBiZ2NvbG9yPSIjRkZGRjAwIj48Zm9udA0KICAgICAgICBjb2xvcj0i
I0ZGMDAwMCIgc2l6ZT0iNCIgZmFjZT0iVmVyZGFuYSI+PHN0cm9uZz5FTUJST0lERVJFRDxicj4N
CiAgICAgICAgPC9zdHJvbmc+PC9mb250Pjxmb250IGNvbG9yPSIjRkYwMDAwIiBzaXplPSIzIg0K
ICAgICAgICBmYWNlPSJWZXJkYW5hIj48c3Ryb25nPlByaWNlcyBJbmNsdWRlIFlvdXIgQ29tcGFu
eSBMb2dvPC9zdHJvbmc+PC9mb250PjwvdGQ+DQogICAgICAgIDx0ZCBhbGlnbj0iY2VudGVyIiB2
YWxpZ249InRvcCIgYmdjb2xvcj0iIzAwRkYwMCI+PGZvbnQNCiAgICAgICAgY29sb3I9IiNGRjAw
MDAiIHNpemU9IjMiIGZhY2U9IlZlcmRhbmEiPjxzdHJvbmc+c2NyZWVuDQogICAgICAgIHByaW50
ZWQ8YnI+DQogICAgICAgIHdpdGggeW91ciBsb2dvPC9zdHJvbmc+PC9mb250PjwvdGQ+DQogICAg
PC90cj4NCiAgICA8dHI+DQogICAgICAgIDx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249InRvcCIg
Ymdjb2xvcj0iI0ZGRkYwMCI+PGZvbnQNCiAgICAgICAgY29sb3I9IiNGRjAwMDAiIHNpemU9IjQi
IGZhY2U9IlZlcmRhbmEiPjxzdHJvbmc+JDExLjk1PC9zdHJvbmc+PC9mb250PjwvdGQ+DQoNCiAg
ICAgICAgPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiBiZ2NvbG9yPSIjMDBGRjAwIj48
Zm9udA0KICAgICAgICBjb2xvcj0iI0ZGMDAwMCIgc2l6ZT0iNCIgZmFjZT0iVmVyZGFuYSI+PHN0
cm9uZz4kMi4xMDwvc3Ryb25nPjwvZm9udD48L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAg
ICAgICA8dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3AiIGJnY29sb3I9IiNGRkZGMDAiPjxh
DQogICAgICAgIGhyZWY9Imh0dHA6Ly93d3cuaGFuZXNidWxsc2V5ZS5jb20vUHJvZHVjdERldGFp
bC5hc3A/U3R5bGU9MDU1WCI+PGZvbnQNCiAgICAgICAgc2l6ZT0iMyIgZmFjZT0iVmVyZGFuYSI+
Y2xpY2sgaGVyZSBmb3IgcHJvZHVjdCBkZXRhaWxzPC9mb250PjwvYT48L3RkPg0KICAgICAgICA8
dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3AiIGJnY29sb3I9IiMwMEZGMDAiPjxhDQogICAg
ICAgIGhyZWY9Imh0dHA6Ly93d3cuaGFuZXNidWxsc2V5ZS5jb20vUHJvZHVjdGRldGFpbC5hc3A/
U3R5bGU9NTI4MCI+PGZvbnQNCiAgICAgICAgc2l6ZT0iMyIgZmFjZT0iVmVyZGFuYSI+Y2xpY2sg
aGVyZSBmb3IgcHJvZHVjdCBkZXRhaWxzPC9mb250PjwvYT48L3RkPg0KICAgIDwvdHI+DQogICAg
PHRyPg0KDQogICAgICAgIDx0ZCB2YWxpZ249InRvcCIgYmdjb2xvcj0iI0ZGRkYwMCI+PHVsPg0K
ICAgICAgICAgICAgPGxpPjxmb250IHNpemU9IjMiIGZhY2U9IlZlcmRhbmEiPkhhbmVzIFBpcXVl
IEtuaXQNCiAgICAgICAgICAgICAgICBHb2xmIFNoaXJ0czwvZm9udD48L2xpPg0KICAgICAgICAg
ICAgPGxpPjxmb250IHNpemU9IjMiIGZhY2U9IlZlcmRhbmEiPjcgb3ouPC9mb250PjwvbGk+DQog
ICAgICAgICAgICA8bGk+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVmVyZGFuYSI+MTYgQ29sb3JzIHRv
IGNob29zZQ0KICAgICAgICAgICAgICAgIGZyb208L2ZvbnQ+PC9saT4NCiAgICAgICAgICAgIDxs
aT48Zm9udCBzaXplPSIzIiBmYWNlPSJWZXJkYW5hIj5NaW4uIDI0PC9mb250PjwvbGk+DQogICAg
ICAgICAgICA8bGk+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVmVyZGFuYSI+Q29udGFjdCBVcyBmb3IN
CiAgICAgICAgICAgICAgICBEaWdpdGl6aW5nPC9mb250PjwvbGk+DQoNCiAgICAgICAgPC91bD4N
CiAgICAgICAgPC90ZD4NCiAgICAgICAgPHRkIHZhbGlnbj0idG9wIiBiZ2NvbG9yPSIjMDBGRjAw
Ij48dWw+DQogICAgICAgICAgICA8bGk+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVmVyZGFuYSI+NTAw
IC0gJDIuMTA8L2ZvbnQ+PC9saT4NCiAgICAgICAgICAgIDxsaT48Zm9udCBzaXplPSIzIiBmYWNl
PSJWZXJkYW5hIj4zMDAgLSAkMi4yNTwvZm9udD48L2xpPg0KICAgICAgICAgICAgPGxpPjxmb250
IHNpemU9IjMiIGZhY2U9IlZlcmRhbmEiPjIwMCAtICQyLjYwPC9mb250PjwvbGk+DQogICAgICAg
ICAgICA8bGk+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVmVyZGFuYSI+MTAwIC0gJDMuMTU8L2ZvbnQ+
PC9saT4NCg0KICAgICAgICAgICAgPGxpPjxmb250IHNpemU9IjMiIGZhY2U9IlZlcmRhbmEiPk1p
bmltdW0gT3JkZXIgb2YgNTANCiAgICAgICAgICAgICAgICBULVNoaXJ0czxicj4NCiAgICAgICAg
ICAgICAgICBhdmFpbGFibGUgYXQgYWRkaXRpb25hbCBjaGFyZ2U8L2ZvbnQ+PC9saT4NCiAgICAg
ICAgICAgIDxsaT48Zm9udCBzaXplPSIzIiBmYWNlPSJWZXJkYW5hIj5PTkUgRlJFRSBTQ1JFRU48
L2ZvbnQ+PC9saT4NCiAgICAgICAgICAgIDxsaT48Zm9udCBzaXplPSIzIiBmYWNlPSJWZXJkYW5h
Ij5QcmljZXMgaW5jbHVkZSB5b3VyPGJyPg0KICAgICAgICAgICAgICAgIDIgQ09MT1IgSU1QUklO
VDwvZm9udD48L2xpPg0KICAgICAgICAgICAgPGxpPjxmb250IHNpemU9IjMiIGZhY2U9IlZlcmRh
bmEiPkhhbmVzIFdoaXRlDQogICAgICAgICAgICAgICAgSGVhdnl3ZWlnaHQ8YnI+DQoNCiAgICAg
ICAgICAgICAgICAxMDAlIENvdHRvbiBULVNoaXJ0IDwvZm9udD48L2xpPg0KICAgICAgICA8L3Vs
Pg0KICAgICAgICA8L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgICA8dGQgYWxpZ249
ImNlbnRlciIgY29sc3Bhbj0iMiI+PGZvbnQgc2l6ZT0iNSINCiAgICAgICAgZmFjZT0idmVyZGFu
YSI+RlJFRSBTQ1JFRU4hPC9mb250PjwvdGQ+DQogICAgPC90cj4NCjwvdGFibGU+DQoNCjwvY2Vu
dGVyPjwvZGl2Pg0KDQo8cCBhbGlnbj0iY2VudGVyIj48Zm9udCBzaXplPSI0IiBmYWNlPSJWZXJk
YW5hIj48c3Ryb25nPlRvIHBsYWNlDQphbiBvcmRlciBvciBnZXQgYWRkaXRpb25hbCBpbmZvcm1h
dGlvbiwgcGxlYXNlIGNvbnRhY3QgdXM6PGJyPg0KPC9zdHJvbmc+PC9mb250PjxhIGhyZWY9Im1h
aWx0bzpDVVNUME1JTUFHRUBuZXRzY2FwZS5uZXQiPjxmb250DQpzaXplPSI1IiBmYWNlPSJBcmlh
bCI+PHN0cm9uZz5DVVNUME1JTUFHRUBuZXRzY2FwZS5uZXQ8L3N0cm9uZz48L2ZvbnQ+PC9hPjxm
b250DQpzaXplPSIzIiBmYWNlPSJWZXJkYW5hIj48c3Ryb25nPjxicj4NCk9SIENBTEwgVVMgVE9M
TCBGUkVFPGJyPg0KPC9zdHJvbmc+PC9mb250Pjxmb250IHNpemU9IjYiIGZhY2U9IlZlcmRhbmEi
PjEtODc3LTUwMy03NDE1PC9mb250PjwvcD4NCg0KPHAgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFj
ZT0iQXJpYWwiPldlIGFyZSBhIGZhbWlseSBvd25lZA0KYnVzaW5lc3MsIG9wZXJhdGluZyBpbiBN
ZW1waGlzLCBUZW5uZXNzZWUgZm9yIG92ZXIgMjkgeWVhcnMuPC9mb250PjwvcD4NCg0KPHAgYWxp
Z249ImNlbnRlciI+PGZvbnQgZmFjZT0iVmVyZGFuYSI+PHN0cm9uZz5TSUdOQVRVUkVTPC9zdHJv
bmc+PC9mb250Pjxicj4NCjxmb250IHNpemU9IjEiIGZhY2U9IkFyaWFsIj5HSUFOVCBTSVpFRCBQ
T1NURVJTICogQ09SUE9SQVRFDQpBUFBBUkVMICogU0lHTlMgJmFtcDsgQkFOTkVSUyAqIFBST01P
VElPTkFMIFBST0RVQ1RTICogVFJPUEhJRVMNCg0KJmFtcDsgQVdBUkRTPC9mb250Pjxmb250IHNp
emU9IjEiPjxicj4NCjwvZm9udD48Zm9udCBmYWNlPSJBcmlhbCxIZWx2ZXRpY2EiPjU1OSBTLiBI
aWdobGFuZCBTdHJlZXQgKg0KTWVtcGhpcywgVE4gMzgxMTE8L2ZvbnQ+IDxicj4NCjxmb250IGZh
Y2U9IkFyaWFsLEhlbHZldGljYSI+OTAxLTMyNy01NDU2PC9mb250PjwvcD4NCg0KPHAgYWxpZ249
ImNlbnRlciI+Jm5ic3A7PC9wPg0KDQo8cCBhbGlnbj0iY2VudGVyIj4mbmJzcDs8L3A+DQoNCjxw
Pjxmb250IHNpemU9IjIiIGZhY2U9IlZlcmRhbmEiPldlIGhvbm9yIHRoZSByZW1vdmFsIHJlcXVl
c3RzDQp0aGF0IHdlIHJlY2VpdmUuPGJyPg0KVG8gYmUgcmVtb3ZlZCBmcm9tIGZ1dHVyZSBtYWls
aW5ncywgcGxlYXNlIGVtYWlsIHVzIGF0IDwvZm9udD48YQ0KaHJlZj0ibWFpbHRvOkRvTm90Q29u
dGFjdFVzQGV4Y2l0ZS5jb20iPjxmb250IHNpemU9IjIiDQpmYWNlPSJWZXJkYW5hIj48c3Ryb25n
PkRvTm90Q29udGFjdFVzQGV4Y2l0ZS5jb208L3N0cm9uZz48L2ZvbnQ+PC9hPjxmb250DQpzaXpl
PSIyIiBmYWNlPSJWZXJkYW5hIj48c3Ryb25nPjxicj4NCg0Kd2l0aCB0aGUgYWRkcmVzcyB5b3Ug
d2FudCByZW1vdmVkIDwvc3Ryb25nPjxlbT48c3Ryb25nPnR5cGVkIGludG8NCnRoZSBTdWJqZWN0
IExpbmUgb2YgeW91ciBlbWFpbDwvc3Ryb25nPjwvZW0+PC9mb250PjwvcD4NCjwvYm9keT4NCjwv
aHRtbD4=
>From elharo AT metalab.unc.edu  Thu Apr 10 15:09:25 2003
Return-Path: <elharo AT metalab.unc.edu>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mail.speakeasy.net (mail11.speakeasy.net [216.254.0.211])
        by happyhouse.metalab.unc.edu (Postfix) with ESMTP id A68BF2007F
        for <xom-interest AT lists.ibiblio.org>;
        Thu, 10 Apr 2003 15:09:24 -0400 (EDT)
Received: (qmail 32404 invoked from network); 10 Apr 2003 19:09:31 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
          (envelope-sender <elharo AT metalab.unc.edu>)
          by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <todd.trimmer AT trizetto.com>; 10 Apr 2003 19:09:31 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p04330101babb713b9f34@[192.168.254.4]>
In-Reply-To: <89297B2626BD5541B479C42E9599B6245D6952@s-coengl-e05>
References: <89297B2626BD5541B479C42E9599B6245D6952@s-coengl-e05>
Date: Thu, 10 Apr 2003 15:06:57 -0400
To: "Trimmer, Todd" <todd.trimmer AT trizetto.com>,
        "XOM list (E-mail)" <xom-interest AT lists.ibiblio.org>
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: Re: [XOM-interest] Sugar syntax
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2003 19:09:25 -0000

At 11:33 AM -0600 4/10/03, Trimmer, Todd wrote:
>If most of the methods of the Node and its ancestors are final, then why
>does sugar syntax hurt so much? It doesn't make a subclasser's job easier or
>harder.
>

Could you be more explicit? I'm not sure what you want to do.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|           Processing XML with Java (Addison-Wesley, 2002)          |
|              http://www.cafeconleche.org/books/xmljava             |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+
>From todd.trimmer AT trizetto.com  Thu Apr 10 16:38:40 2003
Return-Path: <todd.trimmer AT trizetto.com>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from sdc01-x08.trizetto.net (unknown [208.229.189.32])
        by happyhouse.metalab.unc.edu (Postfix) with SMTP id 7EE3F20031
        for <xom-interest AT lists.ibiblio.org>;
        Thu, 10 Apr 2003 16:38:40 -0400 (EDT)
Received: by s-coengl-eb1.tzg.com with Internet Mail Service (5.5.2656.59)
        id <23ASCXTW>; Thu, 10 Apr 2003 14:38:31 -0600
Message-ID: <89297B2626BD5541B479C42E9599B6245D6954@s-coengl-e05>
From: "Trimmer, Todd" <todd.trimmer AT trizetto.com>
To: 'Elliotte Rusty Harold' <elharo AT metalab.unc.edu>,
        "XOM list (E-mail)" <xom-interest AT lists.ibiblio.org>
Subject: RE: [XOM-interest] Sugar syntax
Date: Thu, 10 Apr 2003 14:38:15 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
        charset="iso-8859-1"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2003 20:38:41 -0000

> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo AT metalab.unc.edu]
> Sent: Thursday, April 10, 2003 2:07 PM
> To: Trimmer, Todd; XOM list (E-mail)
> Subject: Re: [XOM-interest] Sugar syntax
> 
> 
> At 11:33 AM -0600 4/10/03, Trimmer, Todd wrote:
> >If most of the methods of the Node and its ancestors are 
> final, then why
> >does sugar syntax hurt so much? It doesn't make a 
> subclasser's job easier or
> >harder.
> >
> 
> Could you be more explicit? I'm not sure what you want to do.
> 


Let's say I propose an absolutely ridiculous and facetious method to be
added to Element. Like getThirdComment(). I can implement this in two ways:
high-level and low-level.

The high-level way will simply build off of other public API:

    public Comment getThirdComment()
    {
        Node child;
        int nComment = 0;
        for (int i = 0; i < getChildCount(); ++i)
        {
            child = getChild(i);
            if (child instanceof Comment)
            {
                ++nComment;
                if (nComment == 3)
                    return (Comment)child;
            }
        }

        return null;
    }

The low-level way attacks the underlying storage directly:

    public Comment getThirdComment()
    {
        Node child;
        int nComment = 0;

        ListIterator liter = children.listIterator();
        while (liter.hasNext())
        {
            child = liter.next();
            if (child instanceof Comment)
            {
                ++nComment;
                if (nComment == 3)
                    return (Comment)child;
            }
        }

        return null;
    }

Now a subclass comes along. He sees getThirdComment(),
getLastProcessingInstruction(), and all kinds of funky stuff. He thinks,
"Great Scott! I have to potentially override all that??!?"

This was a problem in JDOM. If you wanted to subclass Element to represent
every tag in your ML, it took a good while to override all the sugar syntax
methods. If you neglected to, the code might compile anyway, but the
ancestor version of those convenience methods might wind up doing something
nonsensical for your derivative. You had to very diligent.

A low-level written base method might make the subclasses write the WHOLE
METHOD from scratch if the underlying storage was different. The
optimizations in the low-level method in the base class are wiped out in the
override.

A high-level written base method would often warrant the subclasses to do:

    public Comment getThirdComment()
    {
        // pre-processing
        ...

        Comment result = super.getThirdComment();

        // post-processing
        ...

        return result;
    }

Since the high-level way builds off of public API, any changes done to
getChild(int), getChildCount() would propogate to getThirdComment() for
free. This might make the subclasser think he can get away with no having to
override the convenience methods AT ALL.

But what if they way the public API is being used is highly inefficient for
that subclass? What if every call to getChildCount() inside the for loop in
getChildCount() caused a dB query? Or to pull result from a source over a
network?

The point I am trying to make is that cases like these are minimized in XOM,
because most of the methods are final anyway. And the underlying storage is
private. So it would very difficult for a subclasser to make an inherited
convenience method become very non-performant without his knowledge. If the
convenience method is optimized in the base, the chances are very good
indeed it will still be optimized in the derivative. The final/private use
lets us say this with confidence.

This is what I mean when I say it doesn't hurt to add sugar syntax /
convenience methods to XOM as nearly as much as it does in JDOM.

I do realize this is a rather pointless exercise. There are other
philosophical reasons for not wanting a plethora of convenience methods. I
don't think any programmer will satisfied with an OM he didn't roll his own.
At least in Java. I do believe I will be forever doomed to functionally
program XML with library functions passing in the Nodes I want to modify.
Digesting the markup into model-specific JavaBeans as early on as possible
should minimize the pain.

Having said that, I am seeing the wisdom of the micro-kernel approach more
and more. Except for the danged nulls ;-) 

Simply because I don't have the oportunity to create a contextual message
saying WHY the sought after item was not present. A diagnostic trace if you
will. Even if all I wanted to do was a DEBUG level commons logging message
before the null return, I can't. The methods are final. Maybe if there were
were protected preX() and postX() hooks inside these methods. A subclass
still can't tamper with the storage or make the document non-well formed.
The base class would no nothing inside these hooks.

    public class nu.xom.ParentNode
    {
        ...
        public final Node getChild(int pos)
        {
            preGetChild(pos);
            final Node child = children.get(pos);
            postGetChild(pos, child);
            
            return child;
        }

        protected void preGetChild(final int pos) {}

        protected void postGetChild(final int pos, final Node child) {}
        ...
    }

    ---

    public class foo.FooElement extends nu.xom.Element
    {
        ...
        private static final org.apache.log4j.Category log = 
            Category.getLogger(FooElement.class);

        protected void preGetChild(final int pos) 
        {
            if (pos < 0)
            {
                log.warn("Position " + pos + " is less than zero.");
                return;
            }

            if (pos >= getChildCount())
            {
                StringBuffer buf = new StringBuffer("Position ").
                    append(pos).
                    append(" is greater than or equal to the children size
(").
                    append( getChildCount() ).
                    append(") of Element ");

                StringBuffer bufPath = new StringBuffer(getQualifiedName());

                Node node = this;
                while (node.getParent() != null)
                {
                    node = node.getParent();
                    if (node instanceof Element)
                    {
                        bufPath.insert(0, '/');
                        bufPath.insert(0, ((Element)node).getQualifiedName()
);
                    }
                }

                String msg = buf.append(bufPath).append('.').toString();
                log.warn(msg);
            }
        }
        ...
    }


Todd Trimmer
>From elharo AT metalab.unc.edu  Thu Apr 10 16:52:12 2003
Return-Path: <elharo AT metalab.unc.edu>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213])
        by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 071612002C
        for <xom-interest AT lists.ibiblio.org>;
        Thu, 10 Apr 2003 16:52:12 -0400 (EDT)
Received: (qmail 3683 invoked from network); 10 Apr 2003 20:52:19 -0000
Received: from unknown (HELO [192.168.254.4]) ([216.254.85.72])
          (envelope-sender <elharo AT metalab.unc.edu>)
          by mail13.speakeasy.net (qmail-ldap-1.03) with SMTP
          for <todd.trimmer AT trizetto.com>; 10 Apr 2003 20:52:19 -0000
Mime-Version: 1.0
X-Sender: elharo AT mail.ibiblio.org
Message-Id: <p04330100babb89684d78@[192.168.254.4]>
In-Reply-To: <89297B2626BD5541B479C42E9599B6245D6954@s-coengl-e05>
References: <89297B2626BD5541B479C42E9599B6245D6954@s-coengl-e05>
Date: Thu, 10 Apr 2003 16:51:13 -0400
To: "Trimmer, Todd" <todd.trimmer AT trizetto.com>,
        "XOM list (E-mail)" <xom-interest AT lists.ibiblio.org>
From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
Subject: RE: [XOM-interest] Sugar syntax
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2003 20:52:12 -0000

At 2:38 PM -0600 4/10/03, Trimmer, Todd wrote:

>Simply because I don't have the oportunity to create a contextual message
>saying WHY the sought after item was not present. A diagnostic trace if you
>will. Even if all I wanted to do was a DEBUG level commons logging message
>before the null return, I can't. The methods are final. Maybe if there were
>were protected preX() and postX() hooks inside these methods. A subclass
>still can't tamper with the storage or make the document non-well formed.
>The base class would no nothing inside these hooks.


I don't have preX and postX, but I do have checkX methods that will 
be called by any constructor and any method that can mutate a node. 
But I guess you want these in getter methods as well, huh?
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|           Processing XML with Java (Addison-Wesley, 2002)          |
|              http://www.cafeconleche.org/books/xmljava             |
| http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+
>From todd.trimmer AT trizetto.com  Thu Apr 10 17:11:17 2003
Return-Path: <todd.trimmer AT trizetto.com>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from sdc01-x08.trizetto.net (unknown [208.229.189.32])
        by happyhouse.metalab.unc.edu (Postfix) with SMTP id 6C80F20012
        for <xom-interest AT lists.ibiblio.org>;
        Thu, 10 Apr 2003 17:11:16 -0400 (EDT)
Received: by s-coengl-eb1.tzg.com with Internet Mail Service (5.5.2656.59)
        id <23ASCZA5>; Thu, 10 Apr 2003 15:11:05 -0600
Message-ID: <89297B2626BD5541B479C42E9599B6245D6955@s-coengl-e05>
From: "Trimmer, Todd" <todd.trimmer AT trizetto.com>
To: 'Elliotte Rusty Harold' <elharo AT metalab.unc.edu>,
        "XOM list (E-mail)" <xom-interest AT lists.ibiblio.org>
Subject: RE: [XOM-interest] Sugar syntax
Date: Thu, 10 Apr 2003 15:10:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
        charset="iso-8859-1"
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Apr 2003 21:11:17 -0000

> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo AT metalab.unc.edu]
> 
> I don't have preX and postX, but I do have checkX methods that will 
> be called by any constructor and any method that can mutate a node. 
> But I guess you want these in getter methods as well, huh?


Upon deeper reflection, I realized these contextual messages can be built
more appropriately in the application-specific model reflecting the
underlying XML, rather than be built inside the XOM itself. A lower-level
message about the XML won't tell the application user much. Again, your
micro-kernel approach stands strong. I obviously need to think more about
what is appropriate for that which is using XOM and that which is extending
XOM. Limiting XOM extensions to MLs is hopefully the key.


Todd Trimmer
>From g_a_l_l_a AT mail333.com  Wed Apr 16 13:02:40 2003
Return-Path: <g_a_l_l_a AT mail333.com>
Delivered-To: xom-interest AT lists.ibiblio.org
Received: from relay2.hotbox.ru (unknown [62.152.82.179])
        by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 1AB152009E
        for <xom-interest AT lists.ibiblio.org>;
        Wed, 16 Apr 2003 13:02:39 -0400 (EDT)
To: xom-interest AT lists.ibiblio.org
Date: 16 Apr 2003 21:06:23 +0400
Message-ID: <2003.04.16.50A162D8431939DC AT mail333.com>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
From: g_a_l_l_a AT mail333.com
Subject: [XOM-interest] 
        1067938978-ID: We are glad to inform you about the changes in our
        website
X-BeenThere: xom-interest AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: <xom-interest.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/xom-interest>
List-Post: <mailto:xom-interest AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/xom-interest>,
        <mailto:xom-interest-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Apr 2003 17:02:40 -0000

Dear Sir or Madam,
We are glad to inform you about the changes in our website
http://www.gallery-a.ru. Now you can get to know the price for the 
paintings
in our gallery without filling the order form.
Also, we have new works of Utkin Alexandr, Belonog Anatoly and other
painters.
Soon there will be pages of new painters and new section of free wallpapers
and screensavers.
Welcome to our website!
Gallery-a curator.

Sorry if that information not interesting for You and we disturb You with 
our message!
For removing yor address from this mailing list just replay this message 
with word 'unsubscribe' in subject field
or simple click this link:
 
http://www.gallery-a.ru/unsubscribe.php?e=eG9tLWludGVyZXN0QGxpc3RzLmliaWJsaW8ub3JnOjE2NzgxMTk5