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
hoops!

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
APIs.

prakash
--- 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/
>
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 




 

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

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