Uniface Structs: hurdle 1

Author: gianni.sandigliano@unifacesolutions.com (gianni)

I have had a light education on Uniface structs and, since first time I've heard about it, I always looked for an occasion to dedicate to them some deep learning time. Now I need to write a very simple Uniface application to: - Load a received XML from disk - Recognize few specific TAG(S) and get their (sub)value(s) - Write those values into some RDBMS tables - Delete each recognized TAG with its (sub)value(s) - Dump a new XML without those recognized and deleted TAG(S) Because those tags data I should managed are data valid only INTERNALLY at the user company, it is NOT my task to verify a full XML consistency, so for me: - No validation - No verification I am only interested to receive a loadable XML! It's time to test using Uniface struct in a real usecase. ========== ========== ========== ========== First hurdle: a very simple instruction: xmltostruct/full vStruct, "XMLToTestStruct.xml" where "XMLToTestStruct.xml" is a file on disk. It requires MINUTES to answer $status = -1503 and stop loading the XML into vStruct. A further inspection enable to discover the received XML contains few errors in the initial schema declarations part of the document: checking those schema URL with a browser - a first one references to a not existing page - a second one load a page defining itself as outdated from a newer document/page linked into its structure - a third one references to same not existing page as first one NOT an healthy XML this one...but it could happen...it's part of my usecase! Let's find a way to overcome this hurdle? Trying to: - load all referred pages with a browser to get all those errors requires only few SECONDS! - fix errors into XML schema declarations and Uniface is loading the XML in less than 2 seconds. Great! Uniface is obviously doing much more than I really need...and something in a different way, not in line with my needs. Basic questions: 1) Why Uniface is forcing a verification requiring MINUTES to answer back with $status = -1503, while a browser get answered for same pages in SECONDS? 2) Is there any way to avoid Uniface verification just loading into a struct a "well formed XML" (eventually) giving back a warning instead of an error? 3) Using structs in this case am I trying to shoot a sparrow with a cannon? Should I avoid struct, go back to load XML as a text and search strings in it? Thanks in advance for any answer / suggestion / hint. Gianni

Hi Gianni,

gianni said Basic questions: 1) Why Uniface is forcing a verification requiring MINUTES to answer back with $status = -1503, while a browser get answered for same pages in SECONDS?

AFAIK this is a built in functionality of the XML parser Uniface is using. In case a schemaLocation attribute is encountered then the parser will try to load the specified schemas from the specified location. And if one of the schemas fails to load then an error is returned. I'm not sure if the parser has a specific timeout. There's an open issue for this: Issue 31808 — xmlToStruct fails when schemaLocation points to non-existing XML schema

gianni said 2) Is there any way to avoid Uniface verification just loading into a struct a "well formed XML" (eventually) giving back a warning instead of an error?

See workaround for issue 31808 (remove the schemaLocation attribute before loading XML with xmlToStruct).

gianni said 3) Using structs in this case am I trying to shoot a sparrow with a cannon? Should I avoid struct, go back to load XML as a text and search strings in it?

Structs should be the right tool for what you are trying to do here. Processing a struct should be quicker than doing a search (and replace) in a string with Uniface. There are of course ways to speed up string processing, but it should be easier to read/manipulate a XML file with a Struct. Unless you are planning to process very large XML files (> 50MB), in which case it's better to use the UXMLREADER and UXMLWRITER component. Hope this helps. Daniel

diseli said Hi Gianni, ... There's an open issue for this: Issue 31808 — xmlToStruct fails when schemaLocation points to non-existing XML schema

gianni said 2) Is there any way to avoid Uniface verification just loading into a struct a "well formed XML" (eventually) giving back a warning instead of an error?

See workaround for issue 31808 (remove the schemaLocation attribute before loading XML with xmlToStruct). ... Daniel  

Thanks Daniel for your answer. Your proposal is aligned with same decision I was going to take after writing my post. Now, having made further tests under different conditions I've found these two detailed behaviours: A) If network is not loaded (and fast!) Uniface runtime takes MINUTES to give back -1503 on a xmltostruct/full instruction with bad declarations. B) If network is loaded (and slow!) Uniface runtime takes FOREVER on a xmltostruct/full instruction with bad schema definitions and Uniface application is freezing. It's absolutely NOT a nice thing having the application FREEZING under ANY conditions! That means, to write a consistent application, I should strip out first schemaLocations from ALL XML I will receive being them correct or not correct...I feel my application will overcompute a bit but nevertheless this is the way to go! Let's see what next! Gianni

Hi Gianni, Couldn't you try to do a fileload into a component string variable from your network location? Then, do an XMLTOSTRUCT/full.... I'd expect the time to come down quite considerabely... Knut

Knut said Hi Gianni, Couldn't you try to do a fileload into a component string variable from your network location? Then, do an XMLTOSTRUCT/full.... I'd expect the time to come down quite considerabely... Knut  

Ciao Knut, my XML files are already local because are generated from another subsystem at customer site; I've tried various combinations but time (as far as I've understood) is really consumed from xmltostruct/full instruction trying to validate XML also if it is not needed. As far as I've understood the library embedded into runtime has this default default behaviour. IMHO what I've found needed on the field considering an XML could or not include its basic declaration(s) to validate it is: 1) Validate an XMLstream against an embedded DTD/schema without generating a struct => give back a list of positions generating (logical) errors 2) Validate an XMLstream against an external DTD/schema, adding or substituting the embedded one(s), without generating a struct => give back a list of positions generating (logical) errors 3) Generate struct without any validation, get error only if original XML is not a "well formed" XML => give back a list of positions generating (physical) errors 4) Generate struct with embedded validation, use declaration(s) from XML itself to validate it => give back a list of positions generating (logical) errors 5) Generate struct with external validation, defining DTD/schema to validate XML to be added or substituted to declaration(s) from XML itself => give back a list of positions generating (logical) errors AFAIK current Uniface 9.7 is including the more complex things and NOT including those could be considered the simpler ones...but: - Tree structures management is a (very) complex scenario, I am pleased so far of the decision to have structs into Uniface environment - I am still in deep learning mode, trying to apply my experience to struct context I am expecting to post more on this subject... Gianni

diseli said ...

gianni said 2) Is there any way to avoid Uniface verification just loading into a struct a "well formed XML" (eventually) giving back a warning instead of an error?

See workaround for issue 31808 (remove the schemaLocation attribute before loading XML with xmlToStruct). ... Daniel  

Hi Daniel, just to confirm what the workaround means, "remove the schemaLocation attribute" means remove all available: - [prefix:]schemaLocation="value(s) pairs" - [prefix:]noNamespaceSchemaLocation="value(s)" recreating later on into the struct in mmeory the related to struct branch. Right? Gianni

gianni said

diseli said ... See workaround for issue 31808 (remove the schemaLocation attribute before loading XML with xmlToStruct). ... Daniel  

Hi Daniel, just to confirm what the workaround means, "remove the schemaLocation attribute" means remove all available: - [prefix:]schemaLocation="value(s) pairs" - [prefix:]noNamespaceSchemaLocation="value(s)" recreating later on into the struct in mmeory the related to struct branch. Right? Gianni  

Hi Gianni, Yes, that's correct. Daniel