[XML-SIG] Re: Pyx

[Sean McGrath]

[Paul Prescod]
(On Fredericks method)
>It would be trivial to incorporate it into Pyxie and thus relieve Pyxie
>of its dependence on Pyx.

Although doubtless possible, I see no great benefit in doing this.
The "overhead" of a fork in order to read from a pipe does
not bother me. In the overall scheme of things, the overhead
is not significant. Anyway, pipeline processing is awash
with forked processes. C'est la vie.

>#1. You yourself said that it is possible for an XML subset to be its
>own line normalized format.
>
Yes, and I also said I pushed for line-orientation
when XML 1.0 was cooking. But now XML 1.0 is cooked so
the question is now moot.

If we subset XML to produce a similifed line oriented versions,
the powers that be will be very vexed because it will be seen
as fragmenting XML, confusing developers etc. etc. Witness
the SML experience.

Syntactically, PYX is clearly not XML and is in no way
a threat to XML 1.0 and does not confuse developers.

How would you propose that an XML document conforming
to your XML-subset would signal this fact to software?

>#2. Let's ignore that and pretend it is not possible.

And it isn't, for political but not technical reasons.

> It is entirely
>possible to use XML as the interchange format between databases and
>applications and so forth and just use Pyx when it is necessary to make
>the information available as line-oriented information.

You mean "parse" it into PYX. But you are complaining about
parsing overhead and here you are introducing it!

>Translation to
>Pyx can be just the end result of a chain of filters. Therefore you do
>not need ODBC->PYX and HTML->PYX and ...->PYX. You need *->XML and XML->
>Pyx (which you already have). If you start making Pyx "drivers" for
>every data source in the world then you are duplicating all of the work
>that has already been done for XML!

This paragraph pre-supposes a line oriented subset of XML which I believe
to be politically if not technically infeasible at this point.

>
>> Why are you so hostile to it?
>
>I'm not hostile to Pyx. I am hostile to what I see as a very fuzzy
>description of what Pyx does and does not do.
>
With respect, you are using your not insignificant
intelligence to read too much into it! PYX is actually as
simple as it looks. Python, Perl, PHP, PL/1 and Java
programmers have all e-mailed me saying they understand
it, use it, and are thankful for its existence. This makes
me happy. Why can't you be happy too?

>#1. You claim that Pyxie is a Pyx procesing library but I could
>implement the entire Pyxie API without PYX. So let's separate Pyxie and
>Pyx so that we can see what are good and bad about each. The first step
>is to recognize that Pyx and Pyxie they are not at all dependent on each
>other -- except according to your current implementation scheme. So
>Pyxie's API is great and innovative but that derives not one whit from
>Pyx.
Yes, I accept that it is feasible to separate PYX from Pyxie
but they are inextricably linked in my head. Maybe this is
a bad thing...

>
>#2. You claim that we should make pyx generators for ODBC and various
>apps. I claim that the combination of XML and XML->Pyx gives us defacto
>such generators. Therefore we should push for *xml generators* first,
>because they have a much broader utility than Pyx generators.
>

I would look at it differently. A PYX generator is a trivial piece
of work even for those who know nothing about XML. PYX is trivially
and automatically convertable to XML. PYX is perfect as a format
to appear on "standard output" and "standard input" because you
can flow it line by line through a chain until at the  end you
pipe through PYX2XML to get XML on disk. The filters in the
chain do not need to know one iota about XML or XML parsing.
At the same time, they can be as XML savvy as the like.
Pyxie for example, makes a great base for a PYX processing
filter.

>#3. You and I agree that an XML subset can serve as its own
>normalized-line syntax.
Could have. Never happened. XML 1.0 is a done deal. Line orientated
XML is a pipe dream. We have to live with it and move on.

>If software generated this subset then it would
>be automatically compatible with both line-oriented software and with
>XML-compatible software. I cannot see an advantage of Pyx over such a
>subset.
>
Well, PYX exists and the subset does not. PYX does not draw
any wrath from the W3C whereas an XML subset would. Surely
those are advantages!

>I've worked with ESIS for years and it never bothered me. It was a
>useful hack for programming languages (most) that didn't have built-in
>SGML parsers. It remains that for XML and languages like SED, AWK and
>GREP without built-in XML parsers. Fantastic!
>
>What bothers me about it is not that it exists or is used, but merely
>that its importance is exaggerated.
>
>One one page you say this: http://www.digitome.com/Download.html
>
>"The entire Pyxie library revolves around a very simple, line-oriented
>notation for the information emitted by an XML parser. This notation is
>known as PYX. The first character of each line is used to say what type
>of information the line contains:"
>
>And yet, on the example pages, I see nothing that requires any knowledge
>of the Pyx notation AT ALL: http://www.digitome.com/Examples.html
>
>Why would a Pyxie programmer care about the syntax you describe on the
>overview page? In fact, I see the great virtues of Pyx for awk, sed and
>grep programmers, but if I am only interested in Python, why would I
>care whether the input format was line oriented or not?
>

You seem to want to fork the universe. Text tools that understand
XML and text tools that do not. You seem happy to throw away
the tools that are not XML aware. I want to do the opposite.
All text tools understand the concept of a line. Lines
are good. Lines are universal and useful. A lot of useful
work can get done with the line paradigm -- and that includes
XML work -- thanks to PYX.

regards,

http://www.pyxie.org - an Open Source XML Processing library for Python