> 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 th
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
specificatio
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 soft
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
> 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
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 the
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 w
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
>
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
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
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 ;-)
>
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 i
"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?
>
>
>
Thankfully, I'm largely on the periphery of that universe (except for bei
Paul McGuire wrote:
> maybe time to switch to decaf... :)
do you disagree with my characterization of the state of the XML universe?
--
http://mail.python.org/mailman/listinfo/python-list
"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
> softw
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
> p
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
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 ma
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 doi
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 b
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 you
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"
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 serializ
Chas Emerick wrote:
> might be represented as:
>
>
>
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 children, and perhaps stuff everything in a dictionary.
such a constru
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 adv
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
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 "Elemen
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 regar
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 t
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
