OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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:


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">

This specifies that in <c:xxx...> "c;" is the abbreviation that 
specifies that element xxx refers to xxx from the namespace for 

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.

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]