[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] schemaLocation for validating local copies of standards
Josh, I think that's a great idea. I'll try to round up some Java for you. Patti Patti Iles Aymond, PhD Senior Scientist, Research & Development Innovative Emergency Management, Inc. Managing Risk in a Complex World 8555 United Plaza Blvd. Suite 100 Baton Rouge, LA 70809 (225) 952-8228 (phone) (225) 952-8122 (fax) -----Original Message----- From: Josh Shows [mailto:jshows@ESI911.com] Sent: Tuesday, March 27, 2007 8:21 AM To: Rex Brooks; emergency@lists.oasis-open.org Subject: RE: [emergency] schemaLocation for validating local copies of standards Hey Rex (any everyone else), The Adoption SC would love any ideas or content you'd like to work on as part of an instructional cookbook. I'm planning on putting together some coding examples for the .NET platform of standard operations that are part of working with the standards. If there are any other coders out there that would like to contribute examples for other platforms please let me know. (Java would be a big help). Some ideas I've had for examples are: 1. Generating proxy classes from a schema. 2. Validating an xml string against a schema. 3. Consuming a web service that uses one of the standards. DM OPEN would probably be the first choice. --Josh Joshua Shows Software Engineer Emergency Services integrators (ESi) 699 Broad St, Suite 1011 Augusta, GA 30901 706-823-0911 jshows@esi911.com -----Original Message----- From: Rex Brooks [mailto:rexb@starbourne.com] Sent: Sunday, March 25, 2007 10:28 AM To: emergency@lists.oasis-open.org Subject: [emergency] schemaLocation for validating local copies of standards Hi Everyone, One of my action items from last week's TC meeting was to post a message detailing how to provide and specify a locally stored copy of an XMS Schema from a standard rather than requiring a parser to find the document on the web in order to validate it. The problematic part of validating The XML Schema from standards is that you must cite the namespace. This is specified as a URN (Uniform Resource NAME), which is pretty straightforward since we are specifying a NAMEspace. However, a urn just specifies the legal provenance of the NAME. This is the point that is usually missed. You should also specify a URL to the "schemaLocation." If you specify the location where the standard is supposedly, or is supposed to be kept you can get into trouble if the site is down for maintenance or under a denial-of-service attack. Plus you would be wasting bandwidth that is especially important during an emergency incident. If your system's validator can't validate the schema from the remote location, your system could break. So it is better to keep a local version, which also gives you complete control over the correct versioning for your applications. You should keep a correct version of any standard or set of standards your system uses, or that are included within other standards your system uses. However, you still need the schema(s) as separate .xsd files because these are the files you specify in the "schemaLocation" which allows your validator to validate the schema locally and prevent inadvertent failures of the kind mentioned above. For reference, here's an example: http://www.stylusstudio.com/w3c/schema0/schemaLocation.htm For CAPv1.1Errata you need the file: cap1.1.xsd Here's a sample of what I would use: <c xmlns="urn:oasis:names:tc:emergency:cap1.1"> <xsi:schemaLocation=",/your/path/cap1.1.xsd"> This specifies that in <c:xxx...> "c;" is the abbreviation that specifies that element xxx refers to xxx from the namespace for cap1.1. This is a simplification of something that can be greatly complexified for any number of reasons We can't anticipate every need, But, we make sure that we have a zipped file of all standards referenced, "included" and/or "imported" in our standard and a zipped file of all .xsd files from those standards. This way we should be able to prevent the most common kinds of failures. If we also include a clear explanation of how to use our standards in simple, base application examples, it will be much easier to adopt our standards. I would be happy to work with the Adoption SC to develop this into part of the cookbook or set of cookbooks for our specifications, since this particular piece of practical information applies to all of our specifications. Cheers, Rex -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309 IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE: http://www.iem.com/e_mail_confidentiality_notice.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]