emergency-rim — archive

Re: Change Proposal and Validation Issues

From: Rex Brooks
To: [email protected]
Date: Wed, 01 Aug 2018 23:59:00 -0000

Hi Everyone I'm forwarding my reply to Jeff below including my comments inline as I worked through this today. I sent this to him with the zip file that resulted from this effort, which resulted in a version of edxl-tep-v1.1-wd06 that validated for me in XML Spy. I wanted to give you an idea of the extent of the changes we have both applied over the course of this work. For RIM SC there are issues we will want to discuss for arriving at a more complete policy for our specifications moving forward. For TEP SC, I wanted you to have the changes which reflect a policy that is evolving, but that which we have had to apply in the changes made thus far to edxl-tep-v1.1 for it to follow our existing policy requiring it to validate in both XML Spy and Oxygen. So hopefully tomorrow I will be able to post the final version for review before our special telecon meeting Friday. Cheers, Rex On 8/1/2018 9:55 AM, Jeff Waters wrote: Hi, Rex: I thought I would make a blow-by-blow record of my progress validating the version of TEP that you sent me in this email. Step 1) I unzipped the file and found the first schema: edxl-tep-v1.1.xsd and tried to validate in Oxygen. I got a warning saying some of the schema couldn't be found and then an error saying cannot resolve the name ext:ExtensionType . I looked for the three imported schema and they all seemed to be in the correct locations, so then I opened the edxl-ext-v1.0.xsd and it validated fine. But I couldn't find ExtensionType , so I opened the imported schema edxl-ct-v1.0-wd05.xsd and it validated fine (as expected, since if it didn't, I would have gotten an error trying to validate it's parent schema, edxl-ext-v1.0.xsd ). But now the mystery, where is ext:ExtensionType ? So I went looking in docs.oasis-open.org and found that we had dealt with this issue in Sitrep. See http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/cs02/schemas/EDXLSitRep-v1.0.xsd and the schema snippet below with the commented out part: ----------------- <xs:complexType name= IReport abstract= true > <xs:sequence>  <xs:element ref= ext:extension minOccurs= 0 maxOccurs= unbounded /></xs:sequence></xs:complexType> ----------------- As you can see, we have an element extension , but we didn't create and expose an ExtensionType in edxl-ext-v1.0.xsd . So it looks like we need to make the same fix in TEP, that we did in Sitrep. So I commented out line 34 and added line 35 to the edxl-tep-v1.1.xsd schema as shown below and the schema validated. -----------------  <xsd:element ref= ext:extension minOccurs= 0 maxOccurs= unbounded /> -------------- I made this change in the test folder where I duplicated the set of files I sent you. I note that this already included the change in edxl-ct-v1.0-wd05 to correct the typographical error in the name of edxl-gsf-v1.0.xsd. Step 2) I then went up and down the directories and validated by hand each schema I found. The good news is that if I'm connected to wifi, everything validates. The bad news is that if I turn my wifi off, I get errors trying to validate many schema (or at least warnings of incomplete validation) because some of the schemas are importing a couple of our schemas that import files from the internet. Specifically: edxl-gsf-base.xsd imports xlink.xsd from the internet, i.e. <xs:import namespace= http://www.w3.org/1999/xlink schemaLocation= http://www.w3.org/1999/xlink.xsd /> xlink.xsd imports xml.xsd from the internet, i.e. <xs:import namespace= http://www.w3.org/XML/1998/namespace schemaLocation= http://www.w3.org/2001/xml.xsd /> This brings up a decision point that I think we'll have to duck for the sake of edxl-tep-v1.1.xsd. We need to have a policy that provides for the use of an internet sources in our schema. For now, under the necessity of time constraints, I stand by using the following suggestion, the same as I stand by making the typographical correction to the out-of-date edxl-ct-v1.0-wd05. For now we need to make this work, but we need to understand that we'll need to revisit tep once the press of time passes. We need to make a policy for this, and there is a lot of weight behind established practice which uses internet sourcing, but that's a conversation to come. I think our vision was that all of the schemas and sub-schemas would be included, and I know we tackled this issue before, probably for Sitrep. So I went looking in Sitrep and I found these mods: In http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/cs02/schemas/supportingElements/edxl-gsf-v1.0-csd02/edxl-gsf-base.xsd , we commented out the import of the xlink.xsd because it's not being used apparently. So probably we could do the same thing here. I replaced edxl-gsf-base.xsd with commented version in: schemaImportedSchemaedxl-ct-v1.0-csd04, schemaImportedSchemaedxl-ext-v1.0 and schemaImportedSchemaedxl-gsf-v1.0-csd02. Having read this email several times, it seems unlikely that I will attempt to take the four folders of imported schema inside the ImportedSchema folder and condense it into one set of files while changing the schemaLocation for those files every schema where they occur, but... Also in Sitrep http://docs.oasis-open.org/emergency/edxl-sitrep/v1.0/cs02/schemas/supportingElements/ we included xml.xsd in that same directory with xlink.xsd . Again, we could probably make the same change here. I added xlink.xsd and xml.xsd and deleted xlink-2003-12-31.xsd in schemaImportedSchemaedxl-ciq-v1.0-csd04 and I added xml.xsd in schemaImportedSchemaedxl-ct-v1.0-csd04ImportedSchema--Note: must determine correct schemaLocation and schemaImportedSchemaedxl-ct-v1.0-csd04schemaImportedSchema--Note: must determine correct schemaLocation Other observations: * The CIQ schemas appear twice, once with underscores in their names and once with hyphens. By looking at the schemas in the original CIQ spec directory, it looks like the names with hyphens are correct. So we should probably remove the ones with underscores to avoid confusion. Agreed. The question is what happens to specifications that use the wrong old versions? I always thought we could change them as we go along reviewing each spec in turn, but the current time constraint with TEP which we were updating for errors unrelated to these imported schema changes shows us that the idea of a slow, measured approach just isn't what the universe has going on in real time. I'm concerned that just the change to edxl-ct-v1.0.xsd is going to throw us off if we make this change to one single set of imported schema because it specifies its imported schema to be in its own ImportedSchema folder one level further down in the folder structure... I just ran into that the first time I tried to eliminate the edxl-ct-v1.0-csd04 folder to put edxl-ct-v1.0.xsd in ImportedSchema. It's a dilemma I hope you can find a way to fix. * As you note, we have the same CIQ and other schemas copied multiple times into different locations, so we should probably clean this up. So, based on the above, I tried these fixes: (1) I commented out line 34 and added line 35 to the edxl-tep-v1.1.xsd schema, as mentioned above. (2) I commented out the import of xlink (line 20) in EDXL-TEP-v1.1-WD06/schema/ImportedSchema/edxl-gsf-v1.0-csd02/edxl-gsf-base.xsd (3) I started thinking about how to reorganize the imports, ... but I don't think I'll be able to make much more progress today on this, because I have to drive up to LA shortly. I'm thinking maybe we can put all the imported schemas into one ImportedSchema directory, add in the xml.xsd, remove the internet imports, and remove the CIQ schema names that have the underscores. Then maybe we will have one clean, simple organization of schema. Attempting to do this, I placed edxl-ct-v1.0.xsd and edxl-ext-v1.0.xsd in the schema folder so that their relative schemaLocations i.e. ImportedSchema would validate. I changed the schemaLocation for edxl-ext-v1.0.xsd in edxl-tep-v1.0-wd06.xsd to ./edxcl-ext-v1.0.xsd and I eliminated edxl-ct-v1.0-wd05.xsd. And it validated. All files validated in XMLSpy, so I hope it also validates in Oxygen. I sorta don't believe it, but I gotta have my nap now. Cheers, Rex --Jeff On Tue, Jul 31, 2018 at 12:52 PM, rexbroo < [email protected] > wrote: Hi Jeff, I've attached the Word document that details the change proposal we briefly touched on at the start of the RIM SC meeting today, and the seven errors that remained after making sure that all imported schema could be loaded from the folders XML Spy expected to load them from. So you shouldn't see any message complaining that Oxygen can't load any schema. If you do, I must have somehow missed something. The other side of the coin is the duplication errors that remain. To hopefully make it a little easier, I've included the first element error for each file and I added the other folders where the file occurs. I'm tempted to suggest that if Oxygen validates we may want to relax our rule, unless you know of a way to persuade XMLSpy to validate. Thanks, Rex -- Rex Brooks Starbourne Communications Design Email: [email protected] GeoAddress: 1361 Addison St. Apt. A Berkeley, CA 94702 Phone: 510-898-0670 Virus-free. www.avast.com -- Rex Brooks Starbourne Communications Design Email: [email protected] GeoAddress: 1361 Addison St. Apt. A Berkeley, CA 94702 Phone: 510-898-0670