Cart
[Home] [By Thread] [By Date] [Recent Entries]
> > IADS predates web browsers but already used style sheets, > hyperlinking, > etc. It has what you are describing: a fixed vocabulary. In fact, > #FIXED attributes from SGML were an early way to annotate this sort of > thing. It was in fact, a DTD-less SGML browser. > > IOW, there are markup hypermedia browsers (at least one still > standing) that do exactly what you are describing. They > interleave a fixed application language into ANY markup > including ones that already have > their own semantics for links. You may want to note that > what xml:base > does was done with entity declarations once upon a time > before it became > necessary to reinvent them. People such as me have jobs because like > COBOL programmers, we know how those work (meaning I can read > a DTD, edit in Notepad++ and program so I replace four > slots/persons. Cheap!). > > >>That's exactly the problem. Build it into the language, problem > >>disappears! Well ok, there may be other problems. > > Well, build it into a separate language and interleave it > into the rest but we're quibbling syntax and legal/contract > definitions on that one. > Would you believe me if I told you all of this was discussed > endlessly a decade and a half ago? HTML had the upper hand > in that even though it had a crummy browser, it was free and > it worked for the trivial tasks. > Then with mountains of money and publicity, it became the > kudzu of the information age. Now it takes its final > evolutionary form as HTML5: it owns the parse. Of course I would believe it, I was around but not really paying attention (still a problem!). But, don't you mean the browser owns the parse? > > And it will die rather more quickly than anyone suspects, but > that is a prediction yet to be realized. Maybe because MicroXML will replace it? > > >>XML may live on for 1000 or more years, if we make it. > >>How many times can that markup be reinvented? And each > time it gets > >>reinvented is one more reason to not use XML. > > It won't exactly get reinvented. Mauled and rebranded is more > likely. I believe, and John can correct me, MicroXML is a > JSON competitor because it turns out XML is not the best > solution to the problem it was touted to solve: bits on the > wire. On the other hand, let's say Microsoft makes noise > with its Javascript patent, then JSON doesn't look too > healthy and that is precisely why markup if not XML was > invented and why keeping it free of application layers is A > Good Thing. Holy Cow! > > Notice that the markup examples I gave above come from > standards that predate the web by almost a decade. The DTD > used for that is huge and bulky. Not important except to > note that Internet Time and > Inevitability proved to be yet another myth. All > technologies that get > widespread uptake develop like a wildfire until the uptake > reaches some > point of distribution and then switching costs take over. > That is your > main challenge in this proposal. Where the investments are > fairly large, so are the switching costs. I can see that. But at the same time, it could be amortized over a long, long time, right, because not every application is going to start using those hypermedia affordances on day 1. > > That is one reason I have a job. :) They can't afford to move on. Ha! I can certainly see that. Next time you're in Ottawa, I owe you a beer! > > >>I'm on board with XSL! Why do you say was/? > > Some noises that the XSL-FO part of it may be deprecated as solutions > converge around CSS on the web. That will be a problem for > the world I > work in that makes heavy use of XSL-FO with PDF. On the > other hand, it is a tooling problem and we simply buy new > tools, we don't sell them. OK. Much as I liked XSL-FO, it didn't get the traction I thought it was going to so I kind of stopped playing with it. But I always thought making maps with SVG + XSL-FO was a pretty cool idea. Trying to stay off the third rail, Peter
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
