Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Treaty of Wulai
 As usual, Rick, you expose places where I was unclear. Thanks. > > 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. No doubt a name can be used for multiple purposes. That wouldn't be the contradiction. Back to the spec "An XML namespace is a collection of names, identified by a URI reference..." "URI references which identify namespaces are considered identical when they are exactly the same character-for-character. Note that URI references which are not identical in this sense may in fact be functionally equivalent. Examples include URI references which differ only in case, or which are in external entities which have different effective base URIs." And that's all I see there. Am I missing something? I don't see the rider WRT relative URIs. I don't even see that the latter quoted sentence has been modified to reflect this prohibition. But anyway, this shows that there is no contradiction in the spec itself. The contradiction seems to be in the interpretations of the spec given by its editor and other very respectable parties in discussions by the spec. Again Tim Bray: "All attempts to assign meaning to namespace names (which are URI references) are ex post facto and irrelevant to the aims of the namespace recommendation, which is to make names unique for practical purposes in the Internet context." *There's* the contradiction. The spec doesn't prohibit meaning of namespace identifiers and so RDF, SOAP and the CW of namespace=schema have nothing officially in their way. But based on your comments, I think it might just be the usual quiddity over the meaning of "meaning", so I'll move on. > > 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). Again I was unclear, and contradicted myself in the wording (see, pretty easy to do). I did intend to disavow the war over what namespaces must mean. You are right that this would go ten times the famous 1700-message flame-war without satisfactory resolution. It so happens that on this point I am in the minority, including Tim, which thinks that namespaces should have no additional meaning. Given that they are already URIs, I think that applications should not try to resolve namespace URIs for any purpose in the normal course of XML processing (whatever that is). Of course, this is an impractical view given that people expect to be able to retrieve something at least from URLs. I accept this, and it's after this acceptance that comes the war I had in mind. What I would like to be hashed out is a structure for defining the semantics one attaches to namespaces. At its most basic, this could just be a distinction similar to that of well-formed/valid in XML 1.0. Processors could be placed at two distinct layers: one that only treats namespaces as syntax and one that allows using the information represented by the URI itself for processing. Within the latter layer, hopefully there would be some mechanism (even if just prose guidelines) for clearly expressing what semantics are intended by the XML application itself (I mean "application" in the strict sense, what is often called "vocabulary"). This way one processor could operate on both RDF and SOAP and be able to handle the very distinct ways in which they apply semantics to namespaces. > 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. You are right that theoretically there is no problem. The problem comes only in practice, when there is enough pressure applied by the common behavior of XML applications and processors to indeed force it one way or another. Is it not better to put up a flexible framework such that no forcing is necessary? > Having said all that, I certainly agree that more is needed This is the core of what I was getting at. The problem I was was that people are using the sound *theory* of XML NS 1.0 to wave off challengers such as Paul (and Simon St. Laurent before him, and others before Simon) who bring practical concerns. I do think that more specification needs to be made of these matters, especially given the many "facts on the ground" that have accumulated since January 1999. I think that what we have here is the classic database problem of IDs with "business" meaning. It's well known among database designers (whether relational, object or other) that it is a bad idea for IDs of database entities to have any meaning within the application. The obvious example is that you don't use first initial plus last name as the key field in a relational table. The strong form of this principle, however, says that even if you use sequences or random numbes, that you shouldn't use this field for any application-level processing. If you do, even though it originally had no meaning, it will acquire meaning through the behavior of applications and end-users. This meaning will interfere with extensibility and consistency between apps. The ODBMS folks go to great pains to hide object IDs for this reason. Another technology, COM, that came a cross a similar problem as XML 1.0, invented GUIDs as a near fool-proof means of avoiding any application of meaning to digambiguating identifiers. The very ugliness of GUIDs ensures that they won't be exposed except at the low-level COM layer of the application, as intended. I understand that because of the nature of XML, the WG couldn't easily use any of these tricks to avoid the semantic trap. Given that XML namespaces inevitably have meaning, I think there needs to be some effort to ensure extensibility and consistency of XML applications and processors. 'Twould be nice if we could all soak in the waters of Wulai (or y'all could join me in Steamboat Springs) and delicately craft such a framework. Something tells me this is unlikely. -- Uche Ogbuji Principal Consultant uche.ogbuji@f... +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python 
|
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
|
|||||||||
