Page 5 of 8
Re: revxml
Posted: Sat Feb 08, 2014 1:28 pm
by malte
Hi Mark!
Thanks for looking into this. If you sustitute a CR instead of empty I see a problem though:
Code: Select all
<?xml version="1.0" ?>
<root>
<boo>moo</boo>
</root>
on mouseUp
local tTree
put revCreateXMLTree(the text of fld 1,true,true,false) into tTree
answer tTree
revputIntoXMLNode tTree,"root/boo/",cr
put revXMLText(tTree,,true)
revDeleteXmlTree tTree
end mouseUp
would yield:
Code: Select all
<?xml version="1.0"?>
<root>
<boo>
</boo>
</root>
instead of
Code: Select all
<?xml version="1.0"?>
<root>
<boo/>
</root>
What I would expect, and in my case would make a difference...
Is that the case?
Best,
Malte
Re: revxml
Posted: Sat Feb 08, 2014 6:28 pm
by mwieder
Malte: that is indeed the case, and it shouldn't matter. The data content of the xml stream is the same in any event.
AFAIK the third-party libxml library doesn't handle the format of self-closing xml tags.
It may be possible to step around the library and do this from a higher level.
Re: revxml
Posted: Sat Feb 08, 2014 6:50 pm
by malte
ermmm... No, I do not think it is the same.
The same would be:
Using
Contains a character, which is not the same as an empty string when getting the contents of the node.
Re: revxml
Posted: Sat Feb 08, 2014 8:48 pm
by mwieder
<boo /> and <boo></boo> and <boo>
</boo> are exactly the same. The same holds true for
<boo>boo</boo> and <boo>
boo
</boo>
Re: revxml
Posted: Sat Feb 08, 2014 9:17 pm
by malte
Hey Mark,
I might be mistaken, but the following scenario clearly makes a difference:
Code: Select all
on mouseUp
local tTree,tTest
put revCreateXMLTree(the text of fld 1,true,true,false) into tTree
put the number of chars of revXmlNodeContents(tTree,"/root/boo/")
revDeleteXmlTree tTree
end mouseUp
Code: Select all
<?xml version="1.0" ?>
<root>
<boo></boo>
</root>
= 0 characters
Code: Select all
<?xml version="1.0" ?>
<root>
<boo>
</boo>
</root>
= 1 characters
So this would fail in an umpty of places in 2 of my apps where I check for empty nodeContents...
:-/
Re: revxml
Posted: Sun Feb 09, 2014 8:23 am
by mwieder
I might be mistaken, but the following scenario clearly makes a difference:
Indeed it does. The w3 spec is ambiguous as to what should happen, but after talking about this a bit online and in person, I think the whitespace should be conserved. And I found a way to "fix" it so that happens without having to change the third-party library. I adjusted the code accordingly and it should now come out the way you specified.
Re: revxml
Posted: Sun Feb 09, 2014 12:15 pm
by malte
Thank you so much Mark!
Where do I send the bottle to?
Cheers,
Malte
Re: revxml
Posted: Mon Feb 10, 2014 2:38 am
by mwieder
Had another pass at this because I realized that I wasn't preserving child nodes during the replacement.
It's all good now.
But I notice you're setting the last argument to true even though you don't have child nodes of asm_entry to deal with.
For now (until there's a real release with this fix in it) if you leave off the last argument you should be fine.
Re: revxml
Posted: Thu Feb 20, 2014 4:33 pm
by SirWobbyTheFirst
Erm mweider, you didn't deprecate the revXMLChildNames() function did you? I use that all the time and its entry has disappeared from the Dictionary and with reading that you deprecated the revPutIntoXMLNode synonym, I was wondering if you had axed this function or the entry is just missing from the dictionary by accident. It might be a silly question but it is something that I really truly depend on, especially for the file system and configuration systems that I'm building for Nix.
Thanks.
Re: revxml
Posted: Thu Feb 20, 2014 4:44 pm
by Martin Koob
Hi
I am using the revXMLChildNames function in LC 6.5.1 and it is still working. I also checked the dictionary and it is still listed there. Do you mean for LC 6.5.2?
Martin
Re: revxml
Posted: Thu Feb 20, 2014 5:03 pm
by mwieder
Yeah, looks fine to me as well in 6.5.2 and 6.6-dp1.
Re: revxml
Posted: Thu Feb 20, 2014 5:09 pm
by SirWobbyTheFirst
Hmm, I was on 6.5.0 so I'll update and double check.
EDIT: Ah it is listed in the All category but is not listed in the actual XML category. It worked in 6.5.0 but was not shown in the XML category which is usually how I look up functions in a library. My apologies.
Re: revxml
Posted: Thu Feb 20, 2014 7:15 pm
by mwieder
Well, I think it should be showing up in the xml category as well. I didn't change that, and it's a bit of a mystery to me how the source xml files get turned into whatever format the doc files end up as.
So I'd file it as a bug.
Re: revxml
Posted: Mon Mar 10, 2014 9:00 am
by malte
Hi,
there are a couple of regressions still with revXML. I just filed
11903 and am working with my collegues to track down another issue we are seeing, but could not pin down yet.
Best,
Malte
Re: revxml
Posted: Mon Mar 10, 2014 2:24 pm
by LCMark
@malte: I had a look at Bug 11903 and it appears to be due to a 'safety' feature introduced in 2.9. Essentially there are hard-limits in the libxml parser now, which restricts the maximum nesting depth and lookahead the parser does - I presume this is so that large documents can still be parsed, but rather than fail if nesting/node length is too much, it just stop the parsing. (I must confess I'm not entirely sure what problem they are trying to solve here!). However, it's easy enough to fix, we just need to turn off the hard-limits - which (fortunately) there appears to be an option for when creating the document.