[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Another errata?
Mark Birbeck wrote: > Ronald Bourret wrote: > > That this is confusing is evident from the above discussion > > -- John means > > XML namespace and Mark means traditional namespace. > > I'm not confused thanks - I mean both. I am drawing a distinction. You > need both to understand how the namespaces spec implements 'traditional > namespaces' in a manner useful to XML. In short, one, traditional > namespace would not be enough for XML because you lose structure. It > therefore needs a lot of them, and this is achieved by having > effectively a 'namespace container' full of other (real) namespaces. > That namespace container is an 'XML namespace' - which for brevity, we > call a 'namespace'. (Hey, I'm not disagreeing with you that it's > tricky!!) Not only tricky, but unnecessarily tricky. XML should be a tool for real-world business solutions, not something that is more or less a puzzle some CS professor designs for his students. Namespaces is a pain to deal with no matter how you look at it. Once you read a document into memory and no longer preserve the original prefixes (or rather the QName), when you write the document back out (which has possibly been mutated) where do you get these prefixes? Do you simply invent them in the form a, b, c, ..., aa, ab, ac, ... etc. I suppose the people in the "Namespaces in XML" feel that once you read in a document, you throw it away. Under the old PI-Proposal it would be trivial for an XML API to allow the user to assign a prefix to a namespace before writing out an XML Document. Now it is far more difficult and practically impossible to deal with at the application level in a manageable way for the end-user. I suppose only parsing matters anymore with respect to XML and writing out XML documents no longer matters. This is sad as it effectively makes XML useless for my needs in an application I have. > > > It is not the job of standards > > > developers to make sure we understand everything they write. ... > > > > <soapbox> > > Huh? It most certainly *is* the job of the standards > > developers to make > > sure we understand what they write. > > I suppose we're onto matters of opinion now, but a standard must be > unambiguous in its *formal* interpretation. I may read it and > misunderstand, but when I get down to the nitty-gritty of > implementation, provided that I eventually *do* understand it, I should > be able to do this unambiguously. > > If you describe 'intent' then what if you do not cover a usage that > later arises? You introduce ambiguity. If people cannot understand what you write because the ideas are too complex for the average developer, then there is no real point in having a standard in the first place because all that ISV's will be doing is commoditizing their products for a niche market and overall this will reduce innovation in the marketplace. In the end everyone loses here. However, for broadly adopted technologies, standards are very important for application to application interoperability which is something end-users clamor for. But if things are too hard to understand because either the concepts have not been simplified or else the designers of those concepts don't care about clarity, then this does no one any good. > > In contrast, the namespaces spec *is* widely misinterpreted, > > and by people > > who, judging by their posts to this list, are intelligent and > > more than > > willing to read, re-read, and re-re-read specs. To me, that > > says there is > > something wrong, and I think a good example of this is the > > fact that the > > spec repeatedly leads the reader to believe that unprefixed > > attributes > > belong to the namespace of the element. > > The spec does not! The reader's mistaken assumptions about what the > namespaces spec is trying to achieve leads them to read this into it. > But if we're really honest here, if we were in a discussion group on > compiler technology ten years ago, you would not have such a wide range > of people discussing these issues, and narrower range of > misinterpretation (I'm not saying everyone understood everything then > either). That's not to say we shouldn't have more people involved, but I That is because compiler technology is a totally different field (and much more complex field) than XML will ever be. If XML is to be used by only developers and end-users who understand compiler technology then it will fail miserably no matter how much hype is in the presses these days. > disagree with this 'dumbing down' attitude that seems to exist, where we > must ensure that everyone can understand. If you want to write a book > making it clearer then do it - we'd all probably be grateful - but the > spec itself MUST be a formal document. I don't know what your definition of genius is, but mine is simple "the ability to simplify the complex". Quite plainly, if you can make reduce the learning curve for our feeble human minds to understand, it will take less time for people to learn those concepts and they can then take the time they have saved and work on new and interesting tasks. If every generation has to spend most of their adult life just learning everything that the previous generation created (but did not simplify) we will never have progress because human beings will be very old and very grey before they ever get the opportunity to even think original thoughts. > > I think a mistake made in writing many specifications is to rely on > > excessively formal language and write down only the rules, not the > > motivation. In my mind, the point of a specification is not to write > > rules, but to get everybody to agree to the same rules. > > No! The job of the discussion *about* a spec is to find agreement. Once > that has been arrived at you need to codify that in a way that is > unambiguous. It needs to be as formal as possible! If everyone told you to jump off a cliff would you do it? Compromise on technical matters is one of the worst things you can do. I personally feel you should let everyone come up with their own implementations and let public opinion and the marketplace decide who is the best. Compromise usually (but not always) creates groupthink and an atmosphere that very sub-optimal decisions are OK "as long as we can all just get along". > > Finally, if you are driving a technology through standards > > (as opposed to > > the other way around, which is more common), then, whether > > you like it or > > not, those standards necessarily play a role in marketing > > that technology, > > and the more accessible those standards are, the more likely > > the technology > > will succeed. > > I don't think that is the job of standards. Others can write books on > it, produce training courses, and as you say, get hamsters involved in > video production (although I believe that's illegal in some States) but > the standard itself must be as terse and precise as possible. You think people read all of these books and take these training courses because they want to? They take them usually because the technologies they use today are dictated to them. Java's success is an example of people writing code in Java because the "wanted to" because Java took out 85% of the pain in C++. Nevertheless, I have plenty of friends who still write C++ code on new projects using MS Visual C++ because "old grannies" at their institutions think everyone should be doing things they way they did them 10-15 years ago. They can't see the benefits of Java being a simpler version of C++, because they have not made an effort to do so. If you write some spec without regard to simplicity you are falling into a similiar model. "Namespaces in XML" is a pure example of simplicity falling to the wayside in favor of the attitude "well if I can understand it and no one else can, then the whole world is stupid". I think this will change in the next 10 years as people will become fed-up with any company or standards body that does not make a genuine effort at creating simple solutions from the get-go, especially since the trend in business these days is to be leaner and meaner. Microsoft has been eating up the small to medium sized business market with NT because they produce simpler solutions to SUN and IBM even though their OS's may crash all of the time. Even though their customer base is for the most part may be unhappy with their products, finding MS Solution Providers is a lot easier (and cheaper) than finding UNIX engineers. Recently companies like SUN and IBM may be getting the drift, but it may be too little too late. But then again, MS is seemingly doomed to fail big with NT 5.0 (managing 40 million LOC in one build is just plain mind-boggling) so who knows. I just know that my faith in the W3C would be seriously rekindled if "Namespaces in XML" were ripped off the W3C website right now and they started over with a more open-process to create a more well-thought out solution. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
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
|