Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
IBM

IBM Unveiling New Transcoder Technology 61

Posted by Hemos from the entering-that-fun-beta-time dept.
JavaNPerl writes "This Infoworld article states that IBM is about to beta a transcoder that would translate content based on the client. This may get rid of some of the headaches in coding HTML and JavaScript for different clients one day and also make more content available for handhelds. " It's like the Holy Grail - keep seeing glimpes of potential systems, but this sounds like it may be the real thing.
This discussion has been archived. No new comments can be posted.

IBM Unveiling New Transcoder Technology More

IBM Unveiling New Transcoder Technology

Comments Filter:

  • XML (Score:1)

    by Indomitus ( 578 )
    I'd much rather see XML with CSS used as a cross-platform standard in the future but this seems like a good idea as a crutch for older browsers and pages. I'm working on a project to use Perl's XML parser to strip all the extra stuff out of pages like Amazon.com for my own use on my Palm so I don't have to download all the extraneous stuff. If Amazon and other sites used XML and CSS, this task would be much, much, much easier. I hope this thing works though, I've seen some ugly HTML out there and it wouldn't do it mangle it even more.
  • It _is_ a crutch for sloppy content providers aka "webdesigners".

    The HTML 3.2 spec was a braindead way to make the common use of HTML standard i.e. lets pollute HTML with the crap Netscape and Microsoft came up with. Then W3C had to remove the same crap in HTML 4.0 *sigh*.

    If you had a clue what HTML is (or at least tried to be until "webdesigners" had any influence) it wouldn't come as a surprise different user agents present information in different ways. Or maybe you can explain to a blind user why they should care about your colors or typefaces?

    If "webdesigners" didn't misuse HTML they wouldn't have to spend weeks of headache time and the rest of us wouldn't have to suffer from their work.

    Repeat after me - HTML is NOT a layout language.

    /mill
  • This would be nice, but it's not completely true. If you write plain _text_ HTML containing nothing but essential information presented in a way which will fit usefully on the smallest possible screen you won't have a problem (except, of course, people with large screens will get very bored reading little droplets of information at a time).

    Otherwise, HTML's habit of treating the entire file as a single page creates terrible viewing problems which only get worse on smaller screens.

    This would be fixed by a standard which treated your browser window/viewport as an entire page, and formatted accordingly.

    This might also get rid of some of the problems with people printing out stuff all the time -- they do that precisely because there's no document format which presents each view of the document as a complete page, with document progress indicators and links and everything.

    In other words, if you change the width of your window, the document instantly repaginates.

    I suspect I'm not being very clear at this point -- let me know if I'm making sense to anyone.

    -Billy
  • Your point is eloquently put, but I disagree. What you want isn't everything in one document; what you want is for convenient access to all the information via scroll bar.

    IBM's solution clearly fails to provide that (there's no way a server-side solution could), which is why I said it falls short.

    But that doesn't mean that the optimum solution is a single web page -- the problem there, as always, is that on each monitor screen (or printout page) you get partial chunks of information. This can be as trivial as half-visible lines or as nasty as huge tables sliced into incoherent parts.

    The true solution is on the client side.

    Ooops, I said you were wrong. Well, really, you're not. Single-document is the way to go whenever possible. It's just that it isn't the solution to this problem, only an essential part of the correct solution.

    -Billy
  • I claimed that even the best-written HTML wouldn't be well-presentable on devices of widely varying screen sizes.

    This is because, among other problems, people don't like to be shown part of a set of information. HTML implicitly assumes that every web page (HTML file) is a single viewer page, but not even my 21" screen will show all of most web pages (so most pages can't possibly be a single page).

    The problem only gets worse when you add small screen sizes, such as the Pilot.

    The solution is to be a little smarter about displaying information -- you have to think about how much your user can see at once, and be careful not to show them any half-lines of info or half-table cells. Essentially, you should do a single page of repagination every time the user presses the down arrow or pagedown.

    Instead of doing this, modern file display programs either assume that their only job is to display the entire document (HTML, less, MS Word in draft mode) or only display optimally for a single page size which almost no users have on their monitors (Acrobat, Word in page preview, ghostscript).

    This IBM server is interesting because it forces a current format to be reasonably presented on multiple device -- or window -- sizes. It doesn't remove the need for a real document reader, but it sure is better than we've had before.

    -Billy
  • I worked on the framework for this application during the summer. It's much more than a transcoding engine; as the article hints, it's a completely programmable proxy with a plugin API. With it, you can do dynamic HTML not only on the server side but anywhere along the network path of the data flow, allowing for extreme flexibility. For one thing, it allows you to build "Web middleware": grab content from a dynamic site, format it in some way, then pass it along to the client, which may custom-format your formatted text as well. In other words, data can be changed by many compatible third-party agents according to the user's preferences. Imagine being able to customize the Web completely (e.g. to make Slashdot "come in colors everywhere", replacing that ugly green ;) ) . . . with this program, you can do it.

    Check it out at http://www.almaden.ibm.com/cs/wbi/ [ibm.com]. You can download a free but close-source :( version for non-commercial use.

    Beer recipe: free! #Source
    Cold pints: $2 #Product

  • I have to agree with those the others that have said it. Standards compliant HTML 4.0 *is* portable across different clients already.

    What this may do (I couldn't tell from the article) is clean up dirty HTML to make it portable. If so, then yes, it's a fairly clever little piece of software.

    It's not just limited to HTML, either, and may take input in a number of different formats (Word, PDF, SGML, XML, more?). The thing they have to ensure is that their transcoding backbone is extensible enough to cover all possiblities. If they fall into the trap of aiming for the lowest common denominator, it'll be doomed. Hopefully, IBM are smarter than that...

  • It would appear from this type of product announcement press release, which is typical of the *ahem* genre, that the significant problems in computing have already been worked out. All that is remaining is to find mildly creative combinations of functionalities and deficiencies in existing products or methods (this could go into a patent application eh?), and to fire up the buzzword generator to christen it.
  • I'd love to write to a full-featured, fully implemented spec, but until > 90% of any potential audience can view that work as I intended with their 100% compliant and ultra-predictable web browsers, I have to water it down or limp along with workarounds on a per-browser basis.

    This product seems to want to take care of the second problem so you don't have the first problem.

    Right?
  • Whenever I create web pages for some of my sites, I am usually in state of horror when I see how different can the pages be rendered in IE 4/5 and Netscape 4.5/4.6.

    I think you are missing the point. HTML is meant to look different in different browsers, or with different style sheets. It specifies the structure of the document, and then it's up to the browser to display it. Hence the name, Hypertext Markup Language rather than Hypertext Display Language.

    If you want pages to look exactly the same everywhere, use PDF or some other display language.

  • As far as I know, HTML 4.0 is pretty precise. The page can be rendered only in one way correctly.

    Not really - it specifies how to render tables, for example, but it's entirely up to the user what font to choose for headings. This is what style sheets are for.

  • ... (Score:1)

    by Signal 11 ( 7608 )
    But I thought the universal translator already does that. Oh wait... it won't be invented for another 200 years. Nevermind....

    --
  • yup... that they do... I just spent WAY too much time fighting with my post for the same reason... too bad Rob wouldn't put & symbols in the allowed HTML, or at least < and > - I asked some time ago and he basically blew off the suggestion.

    On Fri, 25 Jun 1999, Chris Abbey wrote:

    > Rob, would it be possible to add & constructs (> é " etc...)
    > to the allowed html formating list for comments? Thx. -=Chris

    I think if you post your messages in "Plain Text" mode, those charachters
    are encoded for you. You can't really mix and match, but it works if you
    need those charachters.
  • There've been a few posts on this topic already, and they seem to be headed only down one path from this... "html blah blah blah". Well, yeah that is one path this could take; but not the only, and in fact not the most important.

    Browsers are *one* target recipient, but by no means the ONLY one... palm pilots for example have very little use for full blown HTML 3.x - let alone CSS and Embeded frames, but this technology can target them*. [ *note: I am assuming that this is the same technology that was demonstrated by the SanFrancisco project at javaOne this past June, where both a palm pilot and a browser recieved the same content tailored to their UI and ran the same application logic. If it is then what it can really do will blow your socks off.... if it isn't then I can't wait to see what Research has up it's sleave. ('cause ya's just KNOW us developers don't get license to play with stuff this cool on corp's time...). ]

    Think about this as an *Information Developer* (not an HTML developer, or a "webdesigner")... what do you really want to accomplish? Seperation of content from format? Yes. Targeted formating for a wide variety of presentation systems? Yes! Maintenance of sanity in the process? YES!

    OK, so let's play a hypothetical... you need to put up a simple content component (the building block of a larger information presentation). Let's say you want this component to be called a slashdot poll. So you script up the first polls content:

    [topic name="best PHB tormentor"
    code="phbtorm"
    choice1="frabble-do-hickie"
    choice2="whakka-loofla"
    choice3="nimrod-doodle"
    choice4="source code to current project"]

    (yeah, totally made up grammer... I'm sure it doesn't look anything like that.)

    then you write the first conversion sheet, with a target of text/html ...

    [b]Slashdot Poll[/b]
    [FORM action="http://slashdot.org/pollBooth.pl"]
    [B]$name[/B][BR]
    [INPUT type=hidden name=topic value=$code]
    [INPUT type=radio name=aid value=1]$choice1[BR]
    [INPUT type=radio name=aid value=2]$choice2[BR]
    [INPUT type=radio name=aid value=3]$choice3[BR]
    [INPUT type=radio name=aid value=4]$choice4[BR]
    [INPUT type=submit value=Vote>[/FORM]

    of course you'd really need a lot more (just look at what really is wrapping up the poll) and also be a tad more generic so that you could have a counter that says how many options, and a loop to ittereate and build the form and all that presentation gorp that means nothing to INFORMATION DEVELOPERS. Then you'd turn around and create a second conversion sheet that tells your phonemail system how to present this as a VRS. "Today's slash dot poll is $name. Press or say one for $choice1. Press or say two for $choice2. [...]" (I can already hear the voice of Stephen Halking asking what the past tense of ping is....)

    Now once you've written all those conversion sheets, you're done with them. (unless you want to change you display style for a given target) From then on you can update your information in one form and gaurentee that it will be "properly" presented in all your target platforms.

    Some of you may start down that tired old line that this is what HTML is for, and that new features like CSS give you this. Well yeah, HTML _was_intended_ for this kind of thing - then the "webdesigners" got their hands on it. At that point you have to resort to half assed hacks like CSS to even attempt to preserve the format independent nature of any SGML.

    HTML is OK for the role it has been lead into, but it isn't fullfilling some of the niches people hoped it would because it has been bent to far into another "niche" - the web. Some of the varied devices (in addition to html and VRS mentioned above) that are potential targets include:

    (*> our old friend the green screen - no, it is NOT dead!
    (*> page readers - enabling tech. for the blind
    (*> custom viewers - imagine having the poll as a captive tk/tcl app on your enlightenment docking bar?
    (*> translation systems - the I in IBM is never forgotten... imagine the hassles in translating a billion web pages from English to say Hebrew (right to left) or Kanji (top to bottom, and (I think) right to left)
    (*> PDAs - for those who think PDAs will consume HTML lay off the frapacinno for a while and get a firm grip on reality. Without trying to much to sound like the Linus sound byte about the Nokia 9000s 'mediocre phone, lousy PDA, miserable web browser' - try reading /. on one of those things... trust me when I say the experience sucks rotten eggs.

    But will anyone use it? Well, let's take two case studies of places that COULD have used it... for the first let's look at a major hardware company that lost out on a $250K deal because their web site people had "revamped" their entire corp. web presence to use all the nifty new toys and didn't have the time/resource to update all the old product datasheets... so they dumped them off the servers completely instead: "so they wouldn't clash" with their "consistent face to the consumer".

    For a second let's take good ole Hollerith's Analytical Legacy... last spring they decided to change their page design for all external pages ... just stop and consider the sheer volume that is ... the largest computer company in the WORLD needs to *overnight* revamp their entire site. The process took months to pull off, with entire teams of managers herding the cats, er um... designers, around to get it all accomplished on schedule and make the release date. Every page was copied to an internal server and modified with automated tooling, then every update that was made outside, got mirrored inside untill FINALLY, one night all the server masters did a big remount and moved all that content out to the public. You can still see the results of this on many of thier pages by viewing the source and looking for html comments like this:
    !--Left Navigation here... --

    Now that I've written my content I want to go back and reformat it for HTML... but alas I gotta choose either to show html tags (Extrans) or use html tags ... but not both ... and all three options are destroying my formating ... and Rob wouldn't give me ampersand-l-t-semicolon or ampersand-g-t-semicolon in HTML markup when I asked a few months ago... hhrmmm... let's see what I can do with plain old ascii...... well, after several trips through the preview button and a lot of reworking this looks better...it still looks like crap, and I've now spent more time on FORMAT than on CONTENT... ##*^_@&^!)&@$%^!#)&^$#^$ HTML

  • IBM has been on the XML bandwagon for some time, with their development of xml4j, xml4c (Java and C++ XML parsers) and LotusXSL (a Java XSL implementation). See IBM AlphaWorks [ibm.com] for more info.

  • A large part of the problem is that authors are focused too much on the visual presentation[1], rather than the semantic meaning of the data being presented.

    People forget that denoting something as a list (be it ordered, unordered, or list of definitions) is more important than the list being displayed indented with little swirly bullets next to it.

    Remember -- different page renderings are good -- not everyone has the same needs or wants from data presentation.

    [1] This is especially silly when there's no guarantee that a page will be rendered visually

  • This just encourages the embrace and extend tactics of the Talking Moon. Why conform to standards when you have a magic gizmo that will sort everything out at the last minute? While this might be originally sold as a way to give extranet wireless surfers pared down pages, it will end up with the big Internet sites using this technology to tailor output to diverging browser technologies. Unless you can afford to spring the money to big blue for this proxy server to sit in front of your regular web server you can forget about being a big time player on the Internet 5 years from now. Big Blue will now be actively pressing the browser makers to diverge from standards so that their technology becomes more and more necessary. Definitely a dark day.

  • Damn, I had no idea that this level of integration was going on. It's makes sense, and ultimately cuts out the middle man forever except for maybe things like distribution. I particularly liked reading the XQL spec [w3.org], which I like already.

    One question: XML makes no provisions for security/certification. Will this remain a problem for a lower layer, or will a DTD for this also be designed? Can one nest XML within XML?
  • I have been playing with XML/XSL for awhile, and it sound like IBM's technology is simular, if not the same. XML seemed to be the hot topic for awhile, but I have not yet seen any serious applications for it. Writing DTDs are hard and implementing them in Java applets is even harder.

    Maybe this is what IBM has done... created a replacement framework for these teditious steps.


  • What you're talking about is called a mediator [lfw.org].

    I've been doing this for years. In 1995 i came out with Shodouka, which is a mediator that replaces JIS codes with GIF images so anybody can see Japanese text even if they don't have fonts installed. In 1996 i created MINSE [lfw.org], a semantic expression language with a mediator that lets anybody see math expressions directly embedded in web pages. MINSE was special because, like this so-called "transcoder", it would translate the equation into an appropriate form for the browser: use Netscape, and you get nice antialiased GIF images of the equations; use Lynx, and you get a good attempt at ASCII art. It is still the only way to easily put math on the Web that anyone can view.

    In 1997 i did Crit [crit.org], which enabled anybody to make public annotations on any Web page for the first time. You might want to check that out too (source code is available). It makes all links bidirectional and allows you to make links from your document to a specific phrase in the target document. As a side benefit it shows you some useful metadata about the document which browsers often hide. Again, since it's a mediator, anyone can view or create annotations using any browser -- people running Lynx can attach annotations to anything too.

    The whole idea of "Web middleware" has been around for a long time. I'm pretty sure i was first, but many others have done similar things since then (e.g. Anonymizer, babelfish, and so on). Rohit Khare wrote a nice paper [objs.com] in 1998 summarizing the idea and various applications.


    -- ?!ng

  • ...or Klingon swearing.
  • Uh... well, in a perfect world, this would be true. But have you ever tried looking at a Unix format ASCII file under Windows? Or, I think, the MacOS? Actually, I think there are differences between the MacOS and Windows, also. It's the whole CR/LF issue. Unix only uses one, Windows uses both CR and LF. I think the MacOS only uses one also, but I think it's the other one, not the one Unix uses, but don't quote me on that...
  • The quotes don't belong arround /multiple browsers/, the quotes belong arround /professional web developer/. And Netscape is far from dead.
  • I hate to be a stick-in-the-mud, but the whole point to this web/internet thing is the exchange of information and ideas, not following mindless trends of fashion or creating a bunch of flash that has nothing to do with the material being conveyed. Sure aesthetics are important, but they do not override the value of the content.

    All the html I write is "content enhanced" and designed to be seen in any browser. I don't have problems with backward compatability because I stay away from using tags that are designed to rigidly control the display on the *user's* browser. That was the whole point to HTML and the browser, wasn't it? So that the user gets to control the display of the content? I absolutely stay away from any tag that is browser or platform specific. I want the greatest potential audience for my *content*.

    I guess I'm old guard. In the earliest days of the internet (as some will remember), your access could be terminated for trying to sell something to another person. Just think how much bandwidth we would have available now if there was no spam or "get rich quick...", and worse, chain email.

    Newer is not necessarily better. I have conveyed my message here and didn't use a single HTML tag.

    This has not been intended as flamebait, just and expression of *my* opinion.

    Russ
  • Like it or not, advertising exists. It also works. Much of what you see on the web (good and bad) wouldn't exist without it. Part of this is the creation of advert-based sites. These are meant to look good and feel good. You can't do that with boring old text, as in the original HTML, which was really designed for sharing of research material.

    Microsoft and Netscape added those "evil" tags on demand. Companies wanted a medium to produce their pretty sites in. Nothing else existed, so they used the web. Of course, the "better" course of action would've been to design a medium for this purpose... probably using vector-based graphics and exact specification of display. But, at the moment, HTML is a layout language -- just because Tim Berners-Lee didn't intend or expect it to be used as such doesn't mean it's illegal to use it that way.

    UNIX wasn't designed as a gaming platform, or to be used as a home system.. who cares?!? What can it be used for?

    Many advertisers don't care about the tiny demographic of blind users, or users without the latest browser. The percentage is insignificant to the advertiser. These advertisers choose to make decisions like that, based on projected return. Many of us make our living building these sites. However, although we tend to prefer building good quality sites, sometimes we can't. The budget doesn't allow. This makes us restrict our sites to the latest browsers, or one particular branch of browsers (like Netscape).

    Now what can we do about it? Fight a war between those who want the twiddles and those who don't? OR, how about building a new medium that allows both groups to co-exist? The idea of translating a bad format for compatibility reeks. GIGO.

    We've got all of this noise about XML and XSL, but how much of this is designed by "webdesigners" for "webdesigners"? The concept of "building the right product, rather than building the product right" seems to be completely lost on the W3C. Until they realise that their output isn't necessarily used they way they intended, and then sit down and create something generic, flexible and powerful, we're screwed, and we're going to have this gibbering tower of babel in perpetuity.

    In my opinion, the idea of separating content from presentation is a sound one. However, what won't work is disregarding the importance of presentation over content. Sometimes presentation is more important than content: e.g. for persuading PHBs. It's a sad, odious fact that PHBs control the $$$s. The $$$s pay our bills.

    It's all really about target audiences... the advertisers have target audiences (and I'm afraid geeks who don't want to look at pretty sites are the minority at the moment), and the technologies have target audiences. Things like Flash have particular client target audiences, and those client target audiences have their own consumer target audiences. Use the right tool for the right job. Unfortunately, HTML is the wrong tool for any job right now. What's even worse is that there's no alternative.

    (Apologies for the rambling... I'm sure this post has some valuable points hidden inside!)
  • Yes, Webmethods [webmethods.com] does look useful. I'd have more confidence in it if their web pages were not moronized [www.hut.fi].
  • If you write clean html you won't have that problem.
  • regarding security they decided to let this happen at lower level - ssl, etc being fairly well established.
  • this sounds like its competitive to webmethods [webmethods.com] which is a type of integration/screen scraping crawler that is being used to web-enable sap, etc. essentially you can write a script to extract content from html then turn it into xml then use xsl to transform it to your target dtd. so: you write a script to extract teh data then you go ahead and write xsl stylesheets for your client types.
  • I agree but also want to add that HTML is not portable not only because people don't upgrade their clients, but also because of incompatability between the comparable versions of IE and Netscape browsers. Whenever I create web pages for some of my sites, I am usually in state of horror when I see how different can the pages be rendered in IE 4/5 and Netscape 4.5/4.6. This is especially true for bulleted lists and tables.

    KV

  • Basically, because of the way the Joe User (not us) work, to a detriment to everyone.

    Joe User loves pretty eye candy (usually to the expense of content). So an app that's based on HTML is easy to make eye candy for, and thus "easier" for the user. Plus, it makes things a bit easier for the back-end designer - it's easy to refresh the eye candy to the "now" look than to modify a program to do the same (just a few bits of HTML here and there...).

    Unfortunatly, lots of eye candy, no content. What's worse is javascript...
  • .. to put text translation, rather than having to explicitly invoke Bablefish. Just configure English as your preferred language, and the transcoding proxy will automatically do the translation.
  • This doesn't sound like something new spectacular to me - and from the article I feel that it promises more than it can hold (e.g., I doubt that HTML and JavaScript tweaks could be translated from one client to the other).

    But hey, that's not the point. If I am not mistaken, the thing builds on the philosophy of XML (if not on XML itself). It's about time that more XML complient tools appear on the market, and hopefully these tools will be extendable, and can interact via XML. Seeing that IBM not only jumps onto the XML bandwagon (which is not surprising, as they used SGML for a long time), but also starts to deliver the tools, is a great thing!

  • You are absolutely right if the web is intended as a read only medium which (IMHO) it was originally envisioned to be. Like it or not it has involved into a read write medium and an apllication platform for which it is woefully inadequate. Why people chose a stateless anonymous medium to try and build apps is beyond me but by golly there it is and we gotta deal with it.
    Static web sites are pretty rare these days.
  • One word: Kludge.
  • > I know from experience that standard HTML is one > of the least standardized lingos in computing.

    As far as I know, HTML 4.0 is pretty precise. The page can be rendered only in one way correctly.

    With CSS, it's possible to create layouts, which render OK on older browsers.

    I'm not really in the web development business, but I try to create pages, that render perfectly on standard compilant browsers and OK on the rest.

    In my opinion, this is the only solution. If customers don't see a difference between browser, why should they upgrade to a standards compilant one?
  • HTML includes tags for meaning as for layout. Tags for meaning (like "strong", "li") can be rendered as the browser/user likes.

    Excuse for my stupidness.

  • This is not for fixing javascript & html... (Score:3)

    by visionik ( 63503 ) on Monday September 27, 1999 @09:16AM (#1655901)
    What IBM is really going for here is a way to adapt HTML information into things like WAP (www.wapforum.org) Wireless Markup Language for cell phones & wireless gizmos, and into VoiceXML (www.voicexml.org) for plane-old-telephone access.


  • HTML x.0 is NOT portable! (Score:4)

    by konstant ( 63560 ) on Monday September 27, 1999 @09:41AM (#1655902)
    Many people are commenting that "clean" or "standards-compliant" HTML is already portable across sundry platforms, and therefore this product is only a crutch for sloppy content providers. This is absolutely not true! Having made many webpages myself, and two or three that actually see a lot of use, I know from experience that standard HTML is one of the least standardized lingos in computing.

    The reason is quite simple: people don't upgrade their browsers. Look at www.gnu.org [gnu.org] for pete's sake! That page is specifically designed to be Lynx 2.0 compatible because use of "novelty tags" like (included in the HTML 3.2 spec) will break those clients. As a result, the page is fairly ugly.

    Choose an involved combination of "standard" tags and it's a fairly safe bet that Netscape 3.0 will display it differently than Opera, which will display it differently than IE4, which will display it differently than Netscape 4.5, etc, etc.

    The human is the bottleneck. People don't see a powerful incentive to upgrade their browsers, so they don't. Hence webdesigners like Rob Malda spend weeks of headache time on making their pages BassAckwards 2.7 compliant.

    This transcoder, if it works, will really be a boon.

    -konstant

  • This makes me feel nauseous. Please just write to spec, people! Don't encourage the fragmentation. Web Standards Now! [webstandars.org]

  • When I previewed that previous comment, it looked just great... but when I posted it, I guess the lt and gt entities got re-parsed :-) Here is paragraph #3 without entities:

    It meant using elements for what they were intended for. It meant never using a table for anything other than tabular data. It meant using EM when I wanted emphasis and it meant using CODE when I wanted to mark up code fragments (mind you, I'm stuck using TT right now because /.'s HTML filter doesn't permit CODE!) It took some fiddling.

    Sorry about that, folks!

  • You're on the right track if you're saying that this technology wouldn't even be needed if we could convince people to stick to standards. But you also need one other thing -- well-formedness.

    You can stick to HTML 4.0 [w3.org], even the "Strict" dialect (which I encourage everyone to do!), and still have pages that completely blow up when pulled up outside one of the Big Two. On the website that I accidentally deleted some time ago, I had struggled for some time to not just reach for HTML 4.0 compliance but for well-formedness.

    It meant using elements for what they were intended for. It meant never using a table for anything other than tabular data. It meant using when I wanted emphasis and it meant using when I wanted to mark up code fragments (mind you, I'm stuck using right now because /.'s HTML filter doesn't permit !) It took some fiddling.

    But I turned out with a set of pages that were not only easier to maintain, but CSS applied very cleanly to them, making them pretty and consistent-looking, and they rendered perfectly on any hand-held or speech-synthesizing device you could throw at me. My information was useful to everyone, and that was the best high of all.

    I strongly encourage everyone to pursue well-formedness. The more important stuff that is well-formed instead of hacked, the better browsers we'll get, too!

  • This is a useful tool which, if it works, will mean no more making lame hacks around poorly implemented elements of various browsers to create effects which one's clients often want implemented, against the best advise of their Web developer...

    Also, such middleware for multiple deployability will allow those who are delivering fat content with thin design to do so very easily by coding the content in XML and then transponding...

    Nothing earth-shattering here, but useful...

  • All we really need is one (or both) of two things:

    1. Everyone writing standards compliant HTML for all content. Do the fancy stuff (if you really need to have it) with Java applets or Flash.
    2. Next generation browsers built on XML and a few standard DTD's for different document types. Then all formatting can be done with XSL appropriate to the browser/delivery system/user's special needs.

    Something like this IBM thing is overkill. My guess it will be used by cell phone companies on their proxy servers and otherwise die on the vine. Or, at least, I hope so.

    Jack

  • At first I thought it was some silly translate HTML that IE understands to one netscape understands (silly) - but it look promising - a proxy that allows HTML to be scaled down for handhelds.
    Imagine in the future, two web ports, 80 and 81, 81 for low bandwidth and handheld devices ....and you only have to write the site once - the scaled down stuff is done automatically - kick ass ...wish i thought of this.
  • It won't be invented for 200 years... ...And although it can theoretically translate any language in the universe, it can't deal with whale song.
  • I disagree, there is a fairly large size market that still uses navigator, it does the job, and i simply refuse to use explorer. until a better browser comes along, i'll stick with netscape. Also, I work in IS at my school, every computer there has navigator, so that's about 17,000 people right there, and while that number may be small, there are a lot of situations like that to consider. "I'm Idaho" -Ralph Wiggum
  • Will we be able to tweak the transcoding process? Since _no one_ can know the one-best solution for every enterprise, will it be possible to tweak the output of such a transcoder to your application?? Or possibly modify the IBM-supplied defaults for each browser type??

    Will the framework be available as an API (or preferably an open standard), so that in the future programs (RealEncoder, generator, etc..) could be written to automatically include information in their output for specific formats (i.e. text-only, audio-only, mixed).

    This could be a huge step forward, especially in the days of PCS-based browsers, but can it be done in such a way as to not lock a company down to a specific vendor??
  • What about the Universial Documention Coding : ASCII text files? Anybody can read this using any browsers/doc editors/doc viewers on any OS.

Slashdot Top Deals

Real Programmers don't eat quiche. They eat Twinkies and Szechwan food.

Close