emergency-rim — archive

Re: Change Proposal and Validation Issues

From: Rex Brooks
To: [email protected]
Date: Thu, 02 Aug 2018 15:57:00 -0000

Hi Everyone, I am copying my reply here to Jeff to the RIM SC and TEP SC. I have just confirmed Jeff's conclusion that three schema could be safely deleted as unnecessary (see below and verify in downloaded sip package) and I have posted a revision of the EDXL-TEP-v1.1-WD06.zip package at https://www.oasis-open.org/apps/org/workgroup/emergency-tep/download.php/63643/EDXL-TEP-v1.1-WD06.zip with the Description: This is the most current version as of 08-02-2018 a.m. with schema and ImportedSchema tested to validate as is in XMLSpy subject to confirmation that it also validates in Oxygen. It is to be used for approval at TEP SC telecon meeting 08-03-2018 with included the prose specification documents edxl-tep-v1.1-wd06-TrackedChanges.doc and edxl-tep-v1.1-wd06.doc. Hopefully, Jeff will be able to reply to this message to confirm that this package validates in Oxygen, which will fulfill our policy of confirming validation in both XMLSpy and Oxygen in time for review before we vote to approve the zip package as a new Committee Specification Draft (csd02) and Committee Specification Public Review Draft (csprd02) for a 15-day Public Review. Cheers, Rex On 8/1/2018 11:15 PM, Jeff Waters wrote: Hi, Rex: Wow. Nice work. You did a great job fixing and re-organizing everything. Very nice. I did run into a couple minor issues. My blow-by-blow exploration of the files you sent me is below, but the bottom line, I believe, is that you can eliminate the following schema and everything validates: EDXL-TEP-v1.1-WD06-08012018/schema/ImportedSchema/edxl-ct-v1.0-wd05.xsd EDXL-TEP-v1.1-WD06-08012018/schema/ImportedSchema/xlink.xsd EDXL-TEP-v1.1-WD06-08012018/schema/ImportedSchema/xml.xsd --Jeff My exploration step-by-step: Step 1) I had to change the import statements (lines 9-14) of EDXL-TEP-v1.1-WD06-08012018/schema/ImportedSchema/edxl-ct-v1.0-wd05.xsd to read: ---------------------- <xs:import namespace= urn:oasis:names:tc:emergency:edxl:ciq:1.0:xpil schemaLocation= edxl-xPIL.xsd /> <xs:import namespace= urn:oasis:names:tc:emergency:edxl:ciq:1.0:xal schemaLocation= edxl-xAL.xsd /> <xs:import namespace= urn:oasis:names:tc:emergency:edxl:gsf:1.0 schemaLocation= edxl-gsf.v1.0.xsd /> ---------------------- The problem was that the filenames specified in the schemaLocations didn't match the actual filenames because the edxl-xPIL.xsd and edxl-xAL.xsd were using underscores instead of hyphens, and the actual file edxl-gsf.v1.0.xsd had an extra hyphen in the name specified in the import statement. With these changes, everything validated. Step 2) But interestingly, this is the only file ( ..edxl-ct-v1.0-wd05.xsd ) that didn't validate. There should have been at least one other file to not validate if this schema ( edxl-ct-v.1.0-wd05.xsd ) was being used (imported) by another schema. So to test this, I changed the name of the file ( ...edxl-ct-v1.0-wd05a.xsd ), and everything validated fine, which indicates it isn't being used. So I'm thinking you should be able to get rid of this schema entirely, Step 3) So then I started playing around, changing the names of the other schema files to see if any other schema are not being used. It turns out that when we commented out the import of the xlink.xsd schema in line 20 of EDXL-TEP-v1.1-WD06-08012018/schema/ImportedSchema/edxl-gsf-base.xsd , that was the only schema using EDXL-TEP-v1.1-WD06-08012018/schema/ImportedSchema/xlink.xsd . And xlink.xsd was the only schema using xml.xsd , so it turns out that those two schemas can also be eliminated. Basically, we commented out the need for them. On Wed, Aug 1, 2018 at 3:26 PM, rexbroo < [email protected] > wrote: Hi Jeff, and Everyone (if I copy this wider) Unlike my initial reply, I'm going to add my comments inline as I work through this today. 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-csd04schema ImportedSchema--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 -- Rex Brooks Starbourne Communications Design Email: [email protected] GeoAddress: 1361 Addison St. Apt. A Berkeley, CA 94702 Phone: 510-898-0670