Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Treaty of Wulai (was Re: simple question on namespaces.)
 From: Uche Ogbuji <uche.ogbuji@f...> > Paul is not the first to point out the essential contradiction of the > Namespace WG in saying that namespaces are opaque, meaningless strings in > one breath and then saying that they are URIs in the next. I don't think there is a contradiction. A name can be used for multiple purposes. The URI is *used* as a namespace name. And it can be *used* to locate some retrievable information. And that information could be a schema. Or, if http: is used, we expect it to retrieve something about the namespace. The long-recognized problem, that some people insist that the URI must reference a schema (e.g. SOAP), is now joined by another problem, where some other people now think it must not reference anything. Without an internal convention for representing versions, namespace URIs are not powerful enough to support generic processing with an evolving schema, so the first view (however attractively simple) does not seem workable. But all that the second view denies is that, given that a schema can be decorated with a lot of <appbells> and <appwhistles> which will allow more sophisticated generic processing by schema-aware systems, there are some instances which all processing can be tied to the schema version which is 1:1 with the namespace URI (not needing another resolution step or mechanism, and being upgraded with each version). I think lurking under all this is the deficiency of the "data" versus "document" distinction. What we really have, I think, is more a distinction between 1) generically processable using only information retrieved from the particular schema; 2) not processable without non-schema-representable information; 3) (for orthogonality) processable just as generic XML. I think a lot of the namespace=schema people have documents which fit into the first class. I suspect some of the people for whom !(namespace=schema) is true have documents which fit into the the latter two classes. The reason I bring up data-versus-documents is this: proponents of namespace=schema bring up data-versus-documents where they really seem to mean generically-schema-processable...import of data between databases for example. However, documents that are somehow executable (e.g. SVG, XSL, Gavin Nicol's XEPR, SOAP headers) are not "data" in the sense that generic processing of them according to the information added by a schema will give us much of the value; but they are not "documents". I think that, in the absense of any other considerations, data in class 1) above is best handled by having a schema directly retrievable from the namespace URI. I think for documents in class 2) above, having a schema directly retrievable is a mistake for maintenance reasons at least. I should point out that, in these cases, it is not really the data that belongs to the classes, but the kinds of applications that use the data. That being the case, the question comes down to whether the person creating the data has control of the applications using it: if they have, then they can use namespace URI=schema URI, if not (for reasons of deployment of applications, time and maintenance, public publication, etc.) > However, now we have XSchemas, and there is a sizable body of conventional > wisdom that suggests having an XSD at the business end of a namespace URI. > I'm not sure where this CW comes from, but I have heard and read it often. An interesting rub is how the Schema WG has treated the schema frament for XML namespaces, given that there are different schemas for different versions. Each version has a unique URI, but there is another URI which locates the most recent version. While eventually one hopes XML Schema's syntax will be fixed, nevertheless people may still want to make different versions of the same schema (e.g., to add <appinfo> for specific purposes.) So when talking about whether a schema should be retrievable from a namespace URL, we also have to consider (for maintained schemas) which schema it should be. This certainly leads to the expectation that there will be many uses of namespaces where the namespace URI represents a fairly generic naming mechanism, which does require other mechanisms for finding specific information for optimal processing. The schemaLocation attribute does this: it is called a "hint", but I suspect that any system where the data is not class 1) above (generically schema processable) should use the hint in preference to the namespace URL when attempting to retrieve a schema. > In the spirit of "worse is better", I think we need to begin this > conversation *now*. Yes, but not to go over endlessly the debates of the past, which was Tim's point. The 1700 emails on the public mail-list about relative URLs followed hundreds of emails on private W3C lists and ended up at exactly the same point as the private lists ended (deprecation). So I am trying to suggest is that we do not have a problem with namespaces or URIs here. Rather, it is the age-old problem of generosity: allowing the namespaces spec to be big enough to cope with both class 1) and class 2) applications above, and defending it against attempts to force it one way or another. Having said all that, I certainly agree that more is needed; I don't know that this needs to be an expanded form of the namespaces spec (which perhaps needs an update anyway, now that XML Schemas has gone for 3-part "symbol spaces" rather than two-part Qnames.) > All sides certainly have enough ammo to bring to a War over Namespace > Semantics. Why should we not engage? Because no-one will win. The issues IMHO may ultimately come down to questions of application controllability and not technical issues. So it will divert people from actually putting out interesting and useful tools. Are our lives so long? If they are, could we have it on another list, perhaps namespace-bores@e... ? I propose instead we have a Millennial Namespaces Treaty of Wulai (named after the hot springs where I have been soaking today, looking out at a waterfall on the pretty green opposing valley, feeling like a boiling egg with no timer), where we all agree that in some limited but important circumstances (namespace URI=schema URI) makes sense, and should be allowed, even though the general case should not support (namespace URI=schema URI), though in no case does (namespace=schema). Then the discussion would be on how to cope with this diversity both hygenically and respectfully. In particular, what should UDDI's role be in all this? Cheers "Three Minute" Rick Jelliffe 
|
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
|
|||||||||
