OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] What should TrAX look like? (Was: Re: [xml-dev] Article on

[ Lists Home | Date Index | Thread Index ]
  • To: Elliotte Harold <elharo@metalab.unc.edu>, Michael Kay <mike@saxonica.com>
  • Subject: Re: [xml-dev] What should TrAX look like? (Was: Re: [xml-dev] Article on JAXP 1.3 "Fast and Easy XML Processing")
  • From: Prakash Yamuna <techpy@yahoo.com>
  • Date: Mon, 21 Feb 2005 21:03:52 -0800 (PST)
  • Cc: 'Dare Obasanjo' <dareo@microsoft.com>, 'Prakash Yamuna' <techpy@yahoo.com>, xml-dev@lists.xml.org
  • Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=M7WdWCWUDsLKBUMeD2PhlV1/RVX9UOM+BERN/B6v/+nbCbgkapWpy9ksUZBlCu40IwHmdrhKYcN5CiDMxU5I81v6D2HJZVXn1blKR6RE3NvaBwToF6s5RNL/25aO37abvcZO0E6HdyR3sdBhyNVHiWQzBpSIGTybNoE3o+nXb+0= ;
  • In-reply-to: <421A728C.3000806@metalab.unc.edu>

Sure python folks would convince you of that - that is
because they follow a different programming idiom
(atleast in my mind) and nothing wrong with that...

This is similar to saying why have strongly typed
languages...at some point things will fail... 

I mean if we have learnt anything from the threads
going back and forth on this - it is still difficult
to find a middle ground.

Someday we will apply the 80/20 rule and we will
identify what would be worthwhile to expose to the
client based on the clients need; such that this would
be an interface that most models and implementations
can support without them having to jump thorugh many

Till then I say let it be - why standardize an API
before its time has come?

We see this all over the place...it sure is easier to
build on top of simple APIs than to overhaul existing

--- Elliotte Harold <elharo@metalab.unc.edu> wrote:

> Michael Kay wrote:
> > You know the answer to your question. But it
> doesn't address my point. You
> > claimed that defining the interface to accept
> Source was no better than
> > defining it to accept Object. I pointed out that
> it was better, because
> > defining it as Source would catch many type
> errors. 
> I think the Python folks have pretty well convinced
> me that this doesn't 
> help nearly as much as I used to think. I find it
> hard to imagine a case 
> where I'd pass the wrong object to a transform
> method, and it would 
> survive more than the first test run. These sorts of
> errors are caught 
> so quickly they really don't need special compiler
> support to help them.
> Marker interfaces have their places. Serializable
> doesn't bother me, for 
> instance, because whether an object is serializable
> or not. An object 
> that implements it is probably serializable. An
> object that doesn't 
> isn't. Yes, I know there are exceptions to this; but
> that's basically 
> how it works. Declare an object Serializable and
> ObjectOutputStream will 
> try to serialize it. Declare that an object
> implements Source, and 
> there's little a transformer can do.
> -- 
> Elliotte Rusty Harold  elharo@metalab.unc.edu
> XML in a Nutshell 3rd Edition Just Published!
> http://www.cafeconleche.org/books/xian3/

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS