revxml

[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

[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.

[malte]

ermmm... No, I do not think it is the same.

The same would be:

Code: Select all

<boo></boo>

Using

Code: Select all

<boo>
</boo>

Contains a character, which is not the same as an empty string when getting the contents of the node.

[mwieder]

<boo /> and <boo></boo> and <boo>
</boo> are exactly the same. The same holds true for

<boo>boo</boo> and <boo>
boo
</boo>

[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...
:-/

[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.

[malte]

Thank you so much Mark!

Where do I send the bottle to?

Cheers,

Malte

[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.

[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.

[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

[mwieder]

Yeah, looks fine to me as well in 6.5.2 and 6.6-dp1.

[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.

[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.

[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

[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.