Cart
[Home] [By Thread] [By Date] [Recent Entries]
What if, instead of a browser, sets of browser components were made available, that could be chosen from checkboxes on a form, and then thrown into an architecture, per the particular needs of each "surf" on the web? It's much less of a black box. And it would be harder for only one or two companies to have a monopoly on that box. lisa len bullard wrote: > > Lisa Rein wrote: > > > My point is exactly what Eliot always says -- A lot of this is *NOT* > > rocket science -- as many would have people believe. If it's ooooh soo > > complicated, then scardie-cat developers will have to buy a black box to > > do everything for them. If the world were to discover just how basic > > some of this stuff is -- they might never buy a black box again! > > > > And would that really be so bad? :-) > > > > lisa > > No. After all these years, that would be grand. > > I agree. It is not rocket science, but neither > is scoring music if you are a musician. In this > case, because the root of the web languages is > HTML, there is an entry level and that is what > makes the web go. > > At this time, most companies who want to build an > Intranet have to do it themselves. To afford to > own an Intranet, it has to be organic in its > growth if not its design. The design should be > simple and it should be straightforward to apply > by any discipline of the business. Otherwise, > the businessman has to dedicate personnel > directly to the care and maintenance of multiple > domains. In effect, what one wants is for > each business domain to add its rules to the > framework in business time. As > the business is practiced, the rules emerge > inside the basic navigational structures > the employees build to do their jobs. > > NOTE: As Linux proves, egoboo works. > Still, the framework in which the > structures emerge typically IS designed > by specialists. It is grown by the others. > > As the browser is emerging as the dominant interface > technology, that requires a lot of skill > retooling, particularly in relational > database designs. For a simple example, > look at the design of commercial relational > systems that while excellent for developing > QBE interfaces and involvements, do not take > advantage of the full screen. How should this > be realized in a document interface where > the relational DB is still the principal > server? > > The complexity of this has to be subsumed > in the tools, and I am reasonably convinced > that this requires the black box somewhere > in the toolkit. SGML/XML markup technology > can't get you out of the box. It can make > the box a fairer place, a more truthful place, > and an easier place to do business, but it > is still, for the average bear, slightly > harder than they can do well without > *good, low-cost* tools. A significant contribution > of the XML community to the markup community > is that the second condition will finally be met. > > Cheers, > > Len Bullard > Intergraph Public Safety 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/ 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...)
|
