Fredrik Lundh wrote:
Uche Ogbuji wrote:
I certainly have never liked the aspects of the ElementTree API under
present discussion. But that's not as important as the fact that I
think the above statement is misleading. There has always been a
battle in XML between the people who think
Paul McGuire wrote:
Thankfully, I'm largely on the periphery of that universe (except for being
a sometimes victim). But it is certainly frustrating to see many of the OMG
concepts of the 90's reimplemented in Java services, and then again in
XML/SOAP, with no detectable awareness that these
You'll be surprised at how many XMLers agree that Web services are a
pretty inept reinvention of CORBA. I was pretty much slain by this
take:
http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple
Thanks for that! Sums up nicely my experiences, and gave me a good
Uche Ogbuji wrote:
The fact that the XML Infoset is hardly used outside W3C XML Schema,
and that the XPath data model is far more common, and that focus on
the serialization is even more common than that is a matter of
everyday practicality.
everyday interoperability problems, that is.
On Nov 19, 2006, at 9:55 AM, Fredrik Lundh wrote:
And oh by the way, this thread is all about *your* customer's
complaining.
from what I can tell, it was *your* customer posting FUD about a
different library, not my customer asking for help with a specific
problem. this is free software;
Uche Ogbuji wrote:
The fact that the XML Infoset is hardly used outside W3C XML Schema,
and that the XPath data model is far more common,
and for the bystanders, it should be noted that the Infoset is pretty
much the same thing as the XPath data model; it's mostly just that the
sure, the computing world is and has always been full of people who want
the simplest thing to look a lot harder than it actually is. after all,
*they* spent lots of time reading all the specifications, they've bought
all the books, and went to all the seminars,
and have been sold all the
Uche Ogbuji wrote:
I certainly have never liked the aspects of the ElementTree API under
present discussion. But that's not as important as the fact that I
think the above statement is misleading. There has always been a
battle in XML between the people who think the serialization is
Fredrik Lundh [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
(XML is a bit unusual in this respect, but that's probably just some
variation of the bikeshed effect. it's just text, and everyone with
a keyboard knows what that is, so we don't need to use established
software
Paul McGuire wrote:
maybe time to switch to decaf... :)
do you disagree with my characterization of the state of the XML universe?
/F
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Lundh [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Paul McGuire wrote:
maybe time to switch to decaf... :)
do you disagree with my characterization of the state of the XML universe?
/F
Thankfully, I'm largely on the periphery of that universe (except for being
a
On Nov 18, 2006, at 5:09 AM, Fredrik Lundh wrote:
Uche Ogbuji wrote:
I certainly have never liked the aspects of the ElementTree API under
present discussion. But that's not as important as the fact that I
think the above statement is misleading. There has always been a
battle in XML
Chas Emerick wrote:
and keep patting our-
selves on the back, while the rest of the world is busy routing around
us, switching to well-understood XML subsets or other serialization
formats, simpler and more flexible data models, simpler API:s, and
more robust code. and Python ;-)
That's
On Nov 18, 2006, at 11:29 AM, Fredrik Lundh wrote:
Chas Emerick wrote:
and keep patting our-
selves on the back, while the rest of the world is busy routing
around
us, switching to well-understood XML subsets or other serialization
formats, simpler and more flexible data models, simpler
Chas Emerick wrote:
Further, the fact that ET/lxml works the way that it does makes me
think that there may be some other landmines in the underlying model
that we might not have discovered until some days, weeks, etc., had
passed
so the real reason you posted your original post was to
On Nov 18, 2006, at 1:12 PM, Fredrik Lundh wrote:
Chas Emerick wrote:
Further, the fact that ET/lxml works the way that it does makes me
think that there may be some other landmines in the underlying model
that we might not have discovered until some days, weeks, etc., had
passed
so the
Fredrik Lundh wrote:
Chas Emerick wrote:
If I'm wrong, just chalk it up to the fact that this is the first
time I've ever looked at the Infoset spec, and I'm simply confused.
the Infoset spec *is* the essence of XML; if you don't realize that an
XML document is just a serialization of a
Stefan Behnel wrote:
If you want to copy part of of removed element back into the tree, feel free
to do so.
and that can of course be done with a short helper function.
when removing elements from trees, I often set the tag for those
elements to some garbage value during processing, and then
Stefan Behnel wrote:
[Remove an element, remove following nodes]
Yes, it is. Just look at the API. It's an attribute of an Element, isn't it?
What other API do you know where removing an element from a data structure
leaves part of the element behind?
I guess it depends on what you regard
Paul Boddie wrote:
Yes, it is. Just look at the API. It's an attribute of an Element, isn't it?
What other API do you know where removing an element from a data structure
leaves part of the element behind?
I guess it depends on what you regard an element to be...
Stefan said Element, not
Fredrik Lundh wrote:
It's not very difficult, really; especially if you, as Stefan said,
think in infoset terms rather a sequence of little piggies terms.
Are piggies part of the infoset too? Does the Piggie class represent a
piggie from the infoset plus a stretch of the road to the market?
Thanks for the comments and thoughts. I must admit that I have an
overwhelming feeling of having just stepped into the middle of a
complex, heated conversation without having heard the preamble.
(FYI, this reply is only an attempt to help those that come
afterwards -- I'm not looking to
Chas Emerick wrote:
might be represented as:
Element a: head='', text='last'
Element b: head='first', text='middle'
sure, and you could use a text subtype instead that kept track of the
elements above it, and let the elements be sequences of their siblings
instead of their
On Nov 16, 2006, at 7:25 AM, Fredrik Lundh wrote:
If I'm wrong, just chalk it up to the fact that this is the first
time I've ever looked at the Infoset spec, and I'm simply confused.
the Infoset spec *is* the essence of XML; if you don't realize that an
XML document is just a serialization
Chas Emerick wrote:
The principle and the practice diverge significantly in our neck of
the woods. The current project involves consuming and making sense
of extraordinarily (and typically unnecessarily) complex XHTML.
wasn't your original complaint that ET didn't do the right thing when
On Nov 16, 2006, at 8:12 AM, Fredrik Lundh wrote:
Chas Emerick wrote:
The principle and the practice diverge significantly in our neck of
the woods. The current project involves consuming and making sense
of extraordinarily (and typically unnecessarily) complex XHTML.
wasn't your
Fredrik Lundh wrote:
Stefan Behnel wrote:
If you want to copy part of of removed element back into the tree,
feel free to do so.
and that can of course be done with a short helper function.
Oh, and obviously with a custom Element class in lxml that does this
automatically for you behind
Chas Emerick wrote:
the delta between Elements and DOM-style elements leads to other issues.
There's no doubt that the needed helpers are simple, but all things being
equal, not having to carry them around anywhere we're doing DOM
manipulations is a big plus.
Because we're far from doing
Paul Boddie wrote:
It's not very difficult, really; especially if you, as Stefan said,
think in infoset terms rather a sequence of little piggies terms.
Are piggies part of the infoset too? Does the Piggie class represent a
piggie from the infoset plus a stretch of the road to the market?
Hi,
Chas Emerick wrote:
I looked around for an ElementTree-specific mailing list, but found none
-- my apologies if this is too broad a forum for this question.
The lxml mailing list is always happy to receive feedback, but it's fine to
ask here if it's not lxml specific.
I've been using
30 matches
Mail list logo
