Thank you for the prompt reply. I agree that your solution would solve the
problem that I described. However, it raises two other issues in my mind, one
practical and the other legal/philosophical:
1. The practical problem: What if companyB wants to require its trading
partners to provide specific EXTENDED content, rather than restricted content,
in their instances of TypeA? As I understand it, xsd:redefine only supports
restrictions. It is certainly a real-world case that a specific user of a
vertical-market standard may need additional data in a type defined by a third
party that he wishes to require from his trading partners.
2. The legal/philosophical problem: I had always thought that the sole purpose
of xsd:redefine was to allow a single organization to evolve the definition of
its own schemas over time without having to publish complete replacement
documents. That (I thought) was why its use was restricted to the same
namespace as the original schema. I also thought that xsd:import was the sole
sanctioned way for one organization to make use of another organization's
schema, and that it intentionally provided "read-only" access to the components
defined in the external schema. Aren't there big problems with intellectual
property issues if one organization targets another organization's namespace
and redefines it? Wouldn't it create chaos in a large marketplace if there
were numerous (re)definitions of the same namespace circulating around the web?
Isn't it conceivable or even likely that OrgA may make its schema available to
users on a contractual read-only basis, so that they can import it but not
redefine it? If OrgA's namespace name is derived from a registered Internet
name which might even be trademarked, can other parties just freely redefine
it?
Consider if the xsd namespace itself were redefined by numerous users. Who
could then say anything definitive about the semantics of the various xsd
elements? Wouldn't your solution create similar chaos in a vertical market?
|
