[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Schemas: Best Practices
> If a schema validator ignores schemaLocation (or, as in the case above, > there is no schemaLocation) then the validator is expected to "locate" > the appropriate schemas by some other means. Obviously, if the > validator is unable to locate the appropriate schema then it will fail. My point is that you shouldn't drive validators to their limits in case of XML Schema, especially under the name of "the Best Practice". Consider this. You write a schema and one day you'll find that your schema is no longer usable under your new validator. I'm saying that your technique (I still think it's a trick) will cause troubles like this. It seems to me that you know that one validator accepts your schema, but another may reject it; this is exactly what I meant by an interoperability problem. And technically, I think your explanation is still wrong. A validator has no obligation to locate that schema by the other means. Nor it need to fail the validation. I believe its sole obligation is to report a proper "signal" when that component is actually used. > This is true regardless of whether you're using dangling types or not. Exactly. So I think the best practice should be "do not use include/import without schemaLocation attributes." because it's the best way to avoid possible pitfalls. > pattern, and it is the only way to do many things, e.g., it is the only > way to extend a simpleType. I think that this design pattern will be > used heavily by schema designers. In my work we use it a lot. Well I don't know if it's the only way to do. Maybe so, maybe not. But again, my point is that you should recognize this situation as "extending a simpleType is a risky thing." So we should rather think that such a thing("extending a simpleType") should be avoided as much as possible. Instead, you should look for how to modify your schema so that you don't need to extend simpleTypes. Of course, if you are a schema expert (and I know you are) and you know exactly what you are doing, then that is fine. It's your life. But for average schema authors, which are the target of the best practice text, these tricks are too dangerous. > You are correct that "before" > namespace-coercion occurs the default namespace is the no-namespace. > However, after an <include> the components are no longer in > no-namespace, they are in the targetNamespace of the <include>ing > schema. Hope this clears things up. You are right, but I think you don't oppose my argument. Correct me if my terminology is wrong. The default namespace is a namespace which is declared by xmlns="..." attribute. So as you see, this is the concept of XML namespace. QName is also a concept of XML namespace. And the resolution of QName to (URI,local) pair is also a concept of XML namespace. How QName is resolved to (URI,local) pair is nothing to do with XML Schema. It's a rule that XML namespace calls for. > <xsd:element name="Book" type="CardCatalogueEntry"/> My point is that 1. the above "CardCatalogueEntry" is resolved to the pair of (no-ns,"CardCatalogueEntry") where the author expects it to resolve to ("brabra","CardCatalogueEntry"). 2. The above resolution does not matter who include the schema. 3. So, any schema that includes the above statement will not work as the author expects. > Hmm, you seem to have a different copy than I have. I just looked at > the web site and it defines the camera schema as: Oops, I'm sorry. Actually, I couldn't find the definition of Nikon.xsd, Olympus.xsd, and etc. So I guessed it from your two samples. Would you tell me where I can find the actual definition of three files? > For this issue we don't dictate a "Best Practice". Rather, we point out > the pros and cons of each approach. Each approach has scenarios for > which it is preferred, as we describe in the online document. But the third bullet ("when you need the flexibility of being able to change the schema without ....") is still wrong. This is an advantage of "exposing namespace", not of "hiding namespace" > No, they don't have the same semantics (assuming targetNamespace > provides a level of semantics to components within it). The whole point > is that Chameleon components can have multiple semantics. That's the > power of Chameleon components! OK. Then I would rather say that the chameleon schemas are useless because you can't refer to a declaration in a chameleon schema from the same schema. I'd really appreciate if you would point me out what sections of the spec makes you believe that chameleon schema works. -- Kohsuke KAWAGUCHI +1 650 786 0721 Sun Microsystems kohsuke.kawaguchi@e...
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|