Re: [xml-dev] Streaming XML (WAS: More on taming SAX (was Re:[xml-dev] ANN: Amara XML Toolkit 0.9.0))

["M. David Peterson" <m.david.x2x2x@gmail.com>]

Hi Michael,

This is fantastic information, thank you!  

I actually was nearly complete with this email a few days ago but then
decided that it would be better if I finished up (well, its not
finished, but it is live now) up alphaCOmega.com first and then
responded back after with the fact that this is the primary reason I
am hoping to gain some official understanding of the components that
make up COmega.

If not obvious the site is set up as a place to basically both learn
and then broadcast via various XML feeds the information that is
discovered or the sample code developed.  I see this as a long term
thing as obviously we're still a ways off before we begin to see any
of these features find there way into the official C# >> COmega spec. 
It would, of course, be great to see more people interested in getting
involved with this research project of a research project as obviously
the more sources of quality information the better we as a community
can learn and as such be enabled to begin using any of the language
features as they become available from an official specification >>
CLR, and then subsequent commercial tools, platforms, and applications
support.

I should point out that as far as I can tell (based on my latest
review this morning of the official Microsoft Trademark list >>
http://www.microsoft.com/library/toolbar/3.0/trademarks/en-us.mspx <<
as of yet I haven't crossed any trademark boundaries.  If this is not
the case or if there are future implications that a change of domain
is necessary I will of course comply as expected as it seems based on
the check of my bank balance this morning I'm not as prepared as I
probably ought to be to take on MS in the courtroom ;)  Obviously
trademarks are a serious matter and I don't mean to make lite of any
apparent trademark infringement.  But, at least at the moment, its
seems no lines have been crossed so hopefully things are Ok.

With all this in mind, unless a need to change the name becomes
apparent the site content can be accessed at:

http://www.AlphaCOmega.com

I should note that beyond listing my consulting company as the primary
supporter of this project I have no commercial purpose for this site. 
I think that I can safely assume that any consulting business I gain
in the future will be more than sufficient to foot the ever decreasing
bandwidth and server costs of hosting a site so as far as I'm
concerned thats the only thing beyond an education that I hope to gain
from this venture.  If anybody reading this is interested in getting
involved in this from a learning perspective and as such highliting
their own consulting business (or if MS or MS Research would like to
list related projects, sites, or links to more information I would be
more than happy to post them) I have no issues with that whatsoever
and would love the company as I would imagine this could be quite the
journey.  But beyond that I have no desire to turn this into something
commercial so unless you plan on truly becoming involved with this
then I wouldn't even bother contacting me in regards to posting an
"ad" via a link on the site 'cuz that 'ain't gonna happen ;)

Thanks again for the information Michael!  I'll hold off from posting
any sort of pointer or republication of your reply until there has
been ample time for those on the CC: list to get back into the office
next week and have a chance to, if necessary, respond with any
additional information.  There's obviously no big rush given the
current research stage of COmega so I won't try to rush any content
onto the site until it can be confirmed in one form or another that,
for now at least, it is accurate in regards to the projects current
state at the time of posting.

Looking forward to any involvement that may become of this email!  

Cheers!

<M:D/>


On Fri, 31 Dec 2004 02:49:26 -0800, Michael Rys <mrys@microsoft.com> wrote:
> Let me add Gavin and Erik (who are some of the guys I meant) to the thread to correct me if I am wrong and to counter my personal opinion :-).
> 
> First X#/Xen was basically one research project (not in MSR though :-)) that looked at building a tighter integration of XML querying and manipulation into a programming language (somewhat in the tradition of DB-PL integrations). It provided integration on the type level and some declarative aspects (and got extended later with the tuple aspects).
> 
> C-omega combined that with the concurrency aspect when the project moved into MSR.
> 
> Indeed the main goal is to merge the type systems to a level that you can operate on the "atomic" type instances using a common language framework (in this case a slightly extended C#) instead of inventing a different language that then needs to be embedded.
> 
> My personal opinion is that this is an interesting direction, with the advantage of closing the language/model impedance mismatch between the programming language users and the data query languages and providing better composability of the resulting language than embedding it. However, it also has its problems and pitfalls since it cannot get rid of the non-declarative aspects of the original language while still wanting to provide some declarative subset for optimizability. That's btw, why the APL extensions that Whitney has been working on (or chosing another functional language) have it somewhat easier since APL is closer to a functional, declarative language (once you remove the ->).
> 
> Best regards
> Michael
> 
> > -----Original Message-----
> > From: M. David Peterson [mailto:m.david.x2x2x@gmail.com]
> > Sent: Friday, December 31, 2004 2:34 AM
> > To: Michael Rys
> > Cc: Uche Ogbuji; Daniela Florescu; Alan Gutierrez; Kevin Jones; xml-
> > dev@lists.xml.org
> > Subject: Re: [xml-dev] Streaming XML (WAS: More on taming SAX (was
> > Re:[xml-dev] ANN: Amara XML Toolkit 0.9.0))
> >
> > Hi Michael,
> >
> > From your post:
> >
> > "The guys behind Xen and C-Omega are..."
> >
> > If interpreted without any knowledge that X#, Xen, and COmega were at
> > one point there own very separate projects (or were they?) then this
> > statement suggests/stats that in the case of Xen and C-Omega in some
> > form or another they still are.
> >
> > To try and put an end to my own misunderstandings as to "what is what"
> > and "why" I recently took on a 5 minute research project at the
> > MS-Research site and discovered what I think clarifiies more or less
> > what is implied in your above statement.  Would you mind taking a
> > second to either validate or encourage further research (possible
> > links?) so that I can once and for all get these two/three projects
> > properly defined within my head and as such correct and proper
> > information passed to any readers of future posts to my various
> > blogs/sites in regards to these projects?
> >
> > All of this was found at t the main entry page into the COmega project
> > site under the MS Research umbrella >
> > http://research.microsoft.com/Comega/ <
> >
> > <blockquote>"Cω is an extension of  C# in two areas:
> >
> > - A control flow extension for asynchronous wide-area concurrency
> > (formerly known as Polyphonic C#):
> >
> > links snipped for space...
> >
> > - A data type extension for XML and table manipulation (formerly known
> > as Xen and as X#):
> >
> > links snipped for space....
> >
> > Reasons why these kinds of extensions (and possibly more) are related,
> > are described in this talk:
> >
> >     * Transitions in Programming Models. Luca Cardelli.
> >           o [ <a
> > href="http://research.microsoft.com/Users/luca/Slides/2003-11-
> > 13%20Transitions%20in%20Programming%20Models%20(Lisbon).pdf">
> > PDF</a> ] New University of Lisbon, November 13, 2003.</blockquote>
> >
> > After skimming through "Transitions in Programming Models" by Luca
> > Cardelli it seems that the main, driving reason behind this is that
> > the incompatible nature of the DSL langues being pulled into a much
> > larger master language basically requires things to remain separate
> > until such time that these incosistencies no longer exist and as such
> > can be considered as a direct DSL type extension that has been
> > natively and completely integrated as a first class data type made
> > available via the proper mechanism
> >
> > So am I anywhewre near the target or do I need to dig deepers?
> >
> > Thanks in advance Michael!!!
> >
> > <M:D/>
> >
> >
> >
> > On Fri, 31 Dec 2004 00:09:55 -0800, Michael Rys <mrys@microsoft.com>
> > wrote:
> > > Uche
> > >
> > > I have nothing against Python (and only little against Java :-)), but
> > > one reason that you cannot just use any language that happens to have an
> > > XPath() function is composability of the type system and language.
> > >
> > > If you extend your type system to include all the XSD types and XML node
> > > types, and make the language composable with your XPath expressions, you
> > > will end up either with a new language that is inspired by your
> > > language, but for a new user will have similar complexity to learn as,
> > > for example, XQuery (70% of which is part of XPath 2.0 as well), or a
> > > mess. The only people that will have it simpler are the ones that
> > > already know a bit about your original language.
> > >
> > > Since the W3C due to its make-up cannot decide to just use SQL, Python,
> > > APL, C# or Java as its basis for the XML Query language, it decided to
> > > build XQuery to provide the composability.
> > >
> > > If you decide that you want evolve Python or another language that way,
> > > feel free to do so. The guys behind Xen and C-Omega are looking at this,
> > > as are others (and there used to be a similar approach to embed SQL, for
> > > some better examples, see Arthur Whitney's work).
> > >
> > > Once you have done that, you just created a new language that will
> > > compete with XQuery/XSLT etc that may have some advantages in some
> > > circumstances but will in the end be just another one.
> > >
> > > If OTOH, you are fine with the limited composability since it covers the
> > > 80% use cases for you and the language is declarative (Java or C#
> > > current iterators are not), then you are of course correct that the
> > > syntax does not make much of a difference.
> > >
> > > But then I think Dana would agree. Note that the discussion was about
> > > using low-level processing APIs and not calling an XPATH() processor
> > > within a declarative iterator...
> > >
> > > Best regards
> > > Michael
> > >
> > > PS: I assume that you would choose the iterator's semantics to be
> > > declarative and not procedural...
> > >
> > > > -----Original Message-----
> > > > From: Uche Ogbuji [mailto:Uche.Ogbuji@fourthought.com]
> > > > Sent: Thursday, December 30, 2004 11:44 AM
> > > > To: Daniela Florescu
> > > > Cc: Alan Gutierrez; Kevin Jones; xml-dev@lists.xml.org
> > > > Subject: Re: [xml-dev] Streaming XML (WAS: More on taming SAX (was
> > > > Re:[xml-dev] ANN: Amara XML Toolkit 0.9.0))
> > > >
> > > > On Mon, 2004-12-27 at 13:31 -0800, Daniela Florescu wrote:
> > > > > >     I've gotten pretty good at assembling a SAX engine quickly by
> > > > > >     composing one using resuable strategies.
> > > > >
> > > > > Alan,
> > > > >
> > > > > you didn't answer my question. Besides the personal
> > > > > interest and fun, where there any technical reasons why
> > > > > Xquery/XSLT wouldn't have been the right choice ?
> > > > >
> > > > > Instead of writing Java over SAX, isn't it more convenient
> > > > > to write:
> > > > >
> > > > > for $x in //foobar
> > > > > where some:predicate($x)
> > > > > return my:function($x)
> > > >
> > > > I'd rather write
> > > >
> > > > [ myfunction(x) for x in root.xpath('//foobar') if somepredicate(x) ]
> > > >
> > > > This works *as is* today in Amara toolkit, and is pretty efficient.
> > > >
> > > > So why would I (or you) expect the Python developer to have to learn
> > > > some complex, entirely new programming language to achieve the same
> > > > goal?
> > > >
> > > > >   and leave the smart streaming strategies to implementors
> > > > > to figure out ?
> > > >
> > > > There are smart strategists implementing systems other than XQuery,
> > > you
> > > > know.
> > > >
> > > > > Did you try XQuery/XSLT and fail ? If yes, where did they
> > > > > fell short ?
> > > >
> > > > I'd rather ask you, where there areas where all the many native XML
> > > > processing facilities failed for you, when you decided to develop
> > > > XQuery?
> > > >
> > > > Python and Java came before XQuery, so I don't see why they have to be
> > > > the ones to justify themselves.
> > > >
> > > >
> > > > --
> > > > Uche Ogbuji                                    Fourthought, Inc.
> > > > http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
> > > > Use CSS to display XML - http://www.ibm.com/developerworks/edu/x-dw-x-
> > > > xmlcss-i.html
> > > > Full XML Indexes with Gnosis - http://www.xml.com/pub/a/2004/12/08/py-
> > > > xml.html
> > > > Be humble, not imperial (in design) -
> > > > http://www.adtmag.com/article.asp?id=10286
> > > > UBL 1.0 -
> > > http://www-106.ibm.com/developerworks/xml/library/x-think28.html
> > > > Use Universal Feed Parser to tame RSS -
> > > > http://www.ibm.com/developerworks/xml/library/x-tipufp.html
> > > > Default and error handling in XSLT lookup tables -
> > > > http://www.ibm.com/developerworks/xml/library/x-tiplook.html
> > > > A survey of XML standards - http://www-
> > > > 106.ibm.com/developerworks/xml/library/x-stand4/
> > > > The State of Python-XML in 2004 -
> > > http://www.xml.com/pub/a/2004/10/13/py-
> > > > xml.html
> > > >
> > > >
> > > > -----------------------------------------------------------------
> > > > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > > > initiative of OASIS <http://www.oasis-open.org>
> > > >
> > > > The list archives are at http://lists.xml.org/archives/xml-dev/
> > > >
> > > > To subscribe or unsubscribe from this list use the subscription
> > > > manager: <http://www.oasis-open.org/mlmanage/index.php>
> > >
> > > -----------------------------------------------------------------
> > > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > > initiative of OASIS <http://www.oasis-open.org>
> > >
> > > The list archives are at http://lists.xml.org/archives/xml-dev/
> > >
> > > To subscribe or unsubscribe from this list use the subscription
> > > manager: <http://www.oasis-open.org/mlmanage/index.php>
> > >
> > >
> >
> >
> > --
> > :: M. David Peterson ::
> > XML & XML Transformations, C#, .NET, and Functional Languages Specialist
> 


-- 
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist