XML Schema?

[Alex Martelli]

"Harry George" <hgg9140 at seanet.com> wrote in message
news:m34rxoao2d.fsf at wilma.localdomain...
    [snip]
> > > status.  If that work is focused on one or a few languages, then other
> > > languages have some difficulty staying in the game.
> >
> > ...unless the "other languages" are particularly apt at "fitting into
> > diverse ecological niches" -- Python does that well:-).
>
> Yes, python is extrodinary in that niche.  But we wouldn't be having
> this discusison if it were on top of all the modules that Java is
> covering.

But it *IS* -- just use Jython, hey presto, you're there.


> > > So I'm looking for a low cost way to keep up.  One way is to bind to
> > > libraries generated by others -- that's easier done against C/C++
> > > libraries.
> >
> > Easier than what...?  Definitely not easier than Java/Python
> > integration (with Jython), so I must be misreading you...?
>
> Jython is great -- if you want to use Java.

This is like saying that "CPython is great -- if you want to use C".

A total non-sequitur!  If you want to use C, use C; if you want to
use Java, use Java; Python is great if you want to AVOID using C, or
Java, as much as feasible, while still extracting benefits from
existing libraries that are written in/for those languages.

The correct statements may thus be more like:
J)    Jython is great if you want to use libraries written in/for
        Java (while eschewing use of Java itself as much as possible)
just like:
C)    CPython is great if you want to use libraries written in/for
        C/C++ (while eschewing use of C or C++ as much as possible)

The fact is that, while both statements (C) and (J) are true, (J)
is *far TRUER* -- reusing ANY library written in/for Java (while
eschewing use of Java itself) is a _snap_ with Jython, while the
analogous situation in case (C) often requires *SOME* amount of
C-level work to "wrap" the library specifically for Python use.

> Personally, I don't want
> to lock in to that world.  So I was looking for ways to escape the
> java mindset, not support it.

The Java mindset seems to me to be "one language to bind them
all", etc.  Using a language that is definitely NOT Java thus
escapes "the java mindset" (as I see it) quite effectively,
and Jython is that "language that is definitely NOT Java".

Jython runs only within the *JVM*, of course -- *THAT* is the
unavoidable pre-req for reusing libraries that also run only
within the JVM.  If/when a fully-JVM-specs-compatible JIT or
AOT (ahead-of-time) compiler for JVM-bytecode emerges, then
the libraries in question will be freed from running "within"
the JVM, and so, of course, will Jython be (without any special
effort on the part of anybody EXCEPT the authors of the
hypothetical JVM-bytecode-to-something-else compilers:-).

> Again, I don't want to use or directly link to java.  I want to link
> to other libraries.

You can wrap C-coded or C++-coded libraries with lots of
existing tools such as SWIG, although much manual work
is typically needed.  But that buys you nothing squat, when
"that work is focused on one .. language", given that said
language, in practice, *IS* Java.

With Jython, you will NOT "use or directly link to" *Java* --
you WILL use the bytecodes of the JVM, rather than those
of the dedicated Python VM that's bundled with CPython,
and that's all.

> I already use 4Suite.  As noted elsewhere, it doesn't do XSchema,
> which is why I started this thread.

But neither does the C++ version of Xerces, etc, so, why
DO you at all care about 'linking' to it?!

The (perhaps-sad) current reality is that much research and
development effort regarding bleeding-edge tools is going to
build libraries that will only run within the JVM; the silver
lining in this situation is that Jython rescues you from
having to use Java as the entry-ticket to that world of
rich, bleeding-edge libraries (you do have to be able to
*read* "just enough Java to get by", just like, to use COM
Automation effectively, you have to be able to read just
enough VB to get by, and for a similar reason -- the _docs
and examples_ you will find around will be totally slanted
to Java/VB respectively; fortunately, Java and VB, as used
in docs and examples, tend to be somewhat readable -- it's
NOT as bad as if the examples and docs were slanted to C++
or Perl!-).

If you don't NEED to use certain available-for-JVM-only
bleeding-edge libraries, then CPython appears to me to be
as well-placed as any other language to use other, non-JVM
libraries.  4Suite appears to offer, roughly, about as
much XML functionality, or more, than any other XML suite
of tools that is not JVM-connected.  Easy alternatives
include using COM, which is about as effortless with CPython
(and win32all) as using for-JVM tools with Jython; if a
for-JVM-only tool IS compatible with Microsoft's JVM, you
can probably take advantage of the latter's ability to
expose any Java class as a COM/Automation object to use
it that way (I haven't tried that, and it does not seem
very strategic, given that MS's JVM is not state-of-the-
art any more, and is slowly or not-so-slowly dying).

Near-future possibilities will include XPCOM (a COM work-
alike that was developed within Mozilla and is now well
usable from CPython, thanks to ActiveState's efforts; it
remains to be seen how many bleeding-edge components &c
will in fact be available for it!) and .NET, of which
you say...:

> I may have to eventually use .NET at work, but it will be a cold
> day in Tuxland before I use it at home...

...even if/when it becomes available for, say, Linux as
well as Windows platform, and bleeding-edge tools you
need are only available for it?  Why?

Judging from this assertion, and your total reluctance
to use the JVM (which you appear to be expressing as
a reluctance to use *Java*, which would in fact be well
justified, AND a completely different thing), you would
appear to be allergic to bytecode-based execution
environments.  In which case, it's hard to understand
why you use Python, since, in any of its forms (CPython
with the special-purpose VM, Jython with JVM, Python.NET
with MSIL...), it *DOES* rely on just such bytecode ideas!-)


Alex