Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [About Unicode] Why the symbol LOGICAL NOT is missing from
 Hi Steven, > Your method of assigning a separate character for > each "type" has been used in some programming > languages, notably some BASIC variants, and as a > variable-naming convention in general. It's not > at all a crazy idea, but it runs into some known > problems. Everything we have is a compromise... > First, it's not extensible. Even in your example, > where you assign a different character for each > of several currencies, it seems clear that you > can't do business with very many countries before > the system becomes unmanageable. I would refute that. In the majority of economies, businesses are mostly domestically powered. That is mainly oriented towards serving the local economy. Of course, some countries export more than their fair share, and that is good. Take Japan or Malaysia as an example. Even though they export a heck of a lot.. the people on the ground are very familiar with the Yen and the Ringitt respectively. A little bit of trade is done in dollars and Euros and pounds... but not the majority. > It may not be as > obvious, but most countries that use the Latin > alphabet, also use the same character code for > their currency symbol, even though the symbol > printed differs (try finding a pound-sterling > sign on an American keyboard). Excellent... that makes an even more compelling case for using the $ as a currency field specifier.. > Types are not a handy closed set. Each of the > types you provide is very broad, and even in simple > business data finer distinctions are valuable, e.g. for > validation. Certainly... > Your 'Formula&="F=M*A"' example shows this -- > even in a simple business example, it would be > very valuable to be able to consider formulas as > a different type than strings. Imagine if Excel > couldn't tell the difference, and so all your > formulas got displayed rather than resolved? Come > to think of it, Excel probably does have that > problem for any string that begins with "=" -- > though at least, not too many people's names > begin with '='.... Yes. Well Excel is a fine product. They do support xml these days and have their own way to address the problem you describe above which seems to work quite well. I believe I could show how they could reduce the size of the xml spreadsheet files with my encoding but I'm not exactly needing to be chasing more paid work at the moment. > Second, it's inefficient. A given attribute (or > field, if you prefer) is always the same type, > except in very unusual situations (situations not > supported by much software). So why encode the > type on every instance of the field? Efficiency is becoming such a vague concept in data processing these days. Processors have just gone 64-bit.... and finally 32bit CPUs have run out of memory space... (4GB).. File sizes don't blow out with this markup compared to xml 1.0, in fact they are reduced. > Better to just encode the type for a given field once in > a schema (as is done in XML, SGML, and RDBs) and > avoid redundancy and saying things twice. But don't you find it annoying when you are reading a book and all the time you have to flip to the glossary or appendix to find out what they are talking about. That's the point here. Read without having to flip to another file to get the specification of the field that you are reading. It's much simpler and much more natural. Consequently... it's much more efficient. > Third, it entangles parsing with later > processing. Why should a parser have to know > anything about types at all, as in what > characters are allowed after the equal sign? But it is very efficient for the parser to validate the data after the equals sign once it knows the data-type that it is expecting. > The parser stays simpler if you leave type-checking > to the validator, while the validator can > specialize and be more thorough (like XML schema, > RelaxNG, and others). Yes, the parser stays simple.. but the applications then have to pick up all the slack.. Why not make the parsers more "intelligent" so that the applications can have a more predictable data stream to read from. This is a very interesting area. If my fingers weren't so tired, I would drag up many examples to show what I mean. > > >The other important question or point you mention is readability. In my > >world, the people reading the markup are the business analysts, IT support > >staff or the business owners. They aren't highly trained and need > > something very simple. > > I submit that these people (not to mention > parsers) would have an easier time reading the > syntax without all those type-characters: it's > strictly less stuff to learn. But they "love" certification... :-) > And they don't need > them, because anyone of the sort your describe is > going to know that a field called "quantity" is > numeric, "description" is a string, "date" is a > date, and so on. I don't think so. In business... when something goes wrong and the pressure is on to fix something... the more information that you have on the spot.. the easier it is to fix. > They don't need to be reminded > (or distracted) every single time they see it (or > write it). And if they do forget, it's the kind > of error that a validator *can* catch, so the > consequences of human error can generally be > avoided. After a while, the type characters become so familiar that they fade a little from view and the data being represented is more clearly in view than with traditional xml where the tags seem to get in the way of the underlying data quite a bit. > Also, the enormous number of people who know HTML > or other syntaxes fundamentally like XML would > have to re-train/adjust for your syntax. I have > no problem with that in principle -- but what is > the big advantage that makes it worth their time? 1) Systems that are a bit more reliable and less complex. 2) Less complication in the parsers (but more intelligence) > The biggest problem, I think, is posing Yet > Another Almost XML Syntax. A new syntax requires > new implementations. The cost of those > implementations, and the inability to use > countless existing implementations, surely exceed > the advantages in this case. Yes well... another cost for business... they might even need to spend some extra money to upgrade... :-) but at the same time... they might get new functionality. > A syntax must have > very significant advantages in order to justify a > lot of new implementations. As far as I can see, > your syntax has no *functional* advantages (have > I missed something it can do that XML can't?). It > may have aesthetic advantages (though I myself > don't see them), but if that's all, I don't think > it will be enough to justify all the extra effort. That's what they said about the RS-232c serial port when compared to USB.... :-) Inherent ability to cope with data-typing is a significant improvement and reduces a lot of ambiguity for receiving systems. Consider trying to process: <unknown_data> field1="true" field2="454.56" field3="robin hood" </unknown_data> So many "guesses" need to be made about what type of database table needs to be used to load it. <unknown_data> field1?=True field2$=454.56 field&="robin hood" </unknown_data> To me that almost screams out an sql statement something like: CREATE TABLE `unknown_data` ( `field1` bool, `field2` decimal, `field3` varchar(70)', ); I have everything there needed to do something useful to process the data. btw, the length of field3 can easily be determined simply by reading through the data and finding the maximum length. So I've probably only touched on some of the concepts you've raised, but that is as much as I can say now without my fingers falling off or getting stuck to the keyboard :-) Best Regards David -- Computergrid : The ones with the most connections win. 
|
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
|
|||||||||
