RE: [security-services-comment] Public Comment

["Scott Cantor" <cantor.2@osu.edu>]

> When a normative XML Schema imports another XML Schema it 
> needs to be very specific about the version of schema that is 
> being imported.

I disagree, because XML Schema does not have a normative concept of
"version. It has a non-normative version attribute in the root element that
has no processing rules. The only notion in the spec is namespace. If two
namespaces are the same, they are the same vocabulary.

The fact that people change schemas in incompatible ways (the SSTC being as
guilty as anybody) is a problem, but we can't solve it here (except through
self-discipline).

The way to think about this question is, what schema does the XML Encryption
schema normatively reference? It can't be the one at "the physical location
in the import", because the location there is a hint. It's non-normative.

Quoting the primer:
"Finally, import elements optionally contain a schemaLocation attribute to
help locate resources associated with the namespaces."

It's optional. So if the XMLEnc schema didn't include it, which schema would
be implied? The answer is, the one that is understood to represent the
imported namespace. This can't depend on a physical URL.

> Currently SAML 2.0 schemas reference the following :
> [1] http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
> 
> Above URL is to the latest XMLDSIG schema and may point to a 
> newer version in the future.

And if that version changes namespace, then I'd agree, but as far as I know,
the W3C wouldn't do that, would they? They should publish the new schema at
a different, equally stable, URL.

The point of "newer versions posted here" shouldn't be to imply changes in
the schema, it would be if they added a comment, or made a compatible,
allowable change (e.g. added a new top-level element).

> IMHO, SAML 2.0 schemas should reference [2] and not [1] 
> because [1] is an unstable URL whose resource will change over time.

I think allowing the schema to change over time without changing the
namespace would be a much deeper problem. If anything, we should enforce
this understanding by making sure we refer to the URL we use now so nobody
gets the wrong idea...

But somebody more familiar with W3C policy ought to address this question as
well.

-- Scott