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: dareo@microsoft.com, xml-dev@lists.xml.org
  • 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: Fri, 18 Feb 2005 13:07:27 -0800 (PST)
  • Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=1qR/sfR5cLlnVCcBigAAq66cmNM0tGu50+gv/YxuzoXaiQf/1HOnRRQpxzZMW/2Q4QYzgq+Go/lMZaYQpEuTLs+ABrFNKus+pRbl+to9FFULf5501q8kvxXbT+2UlH3eYtsaO2TAZED6Al31o8H3Bv7Yw+xUWwjWIJkt+kx+o/g= ;

I find Source more useful - sure it is very light
weight and has little value.

But what it has done is put a stake in the ground so
to speak.

Everybody who implements Source will adhere to the
interface.

This becomes very useful from an evolution
perspective. The reason it is underspecified is a lot
of models have disparate needs and there has been no
common agreement on how they can expose it.

But over time as things mature and our understanding
increases - the disparate models, implementations can
come to an understanding on what their needs would be
- at that point Source can evolve further and there
can be more meat to its interface.

But because of the fact all the models decided to
adhere to Source - they will support this much heavier
interface.

The comparison to .NET interfaces may not be very
meaningful because the considerations may be different
in my mind.

As you mention the consideration in the .NET design
was usability (in terms of less lines of code).

The consideration for Source may also include varied
implementations and how they can still provide certain
guarantees (even if these are actually non-existent
today) - when you are designing such a system it is
best to underspecify rather than overspecify.

Disclaimer:
I don't claim I understand .NET interfaces - so please
feel to ignore my comments.

prakash
> -----Original Message-----
> From: Paul R Brown [mailto:prb@fivesight.com] 
> Sent: Thursday, February 17, 2005 11:14 AM
> To: 'XML Developers List'
> Cc: 'Elliotte Harold'; Michael Kay
> Subject: Re: [xml-dev] What should TrAX look like?
(Was: Re: 
> [xml-dev] Article on JAXP 1.3 "Fast and Easy XML
Processing")
> 
> 
> I also go so far as to say that the discussion is a
bit misdirected: 
> the apparently poor encapsulation of Source is more
of a 
> symptom of the fact that TrAX transformers (e.g.,
XSLT 
> processors but potentially STX or XQuery or...?)
need to be 
> able to implement their underlying model however
they so 
> choose.  Source is little more than a marker
interface, and 
> the thing that makes sense (at least to me) is to
have 
> off-the-beaten-path Source implementations (e.g.,
for a pull 
> parser) exhibit enough polymorphism (implement
SAXSource, 
> DOMSource, etc.) to make them useful and reasonably
portable 
> for consumption by different Transformer
implementations.

Marker interface is a synonym for design flaw. 

--
PITHY WORDS OF WISDOM 
No matter how long or how hard you shop for an item,
after you've 
bought
it, it will be on sale somewhere cheaper.   

This posting is provided "AS IS" with no warranties,
and confers no
rights.  


		
__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page – Try My Yahoo!
http://my.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