Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Novell (NOVL) dirt cheap, good buy? -- Ignore unavailable to you. Want to Upgrade?

To: Paul Fiondella who wrote (27248)	6/27/1999 11:22:00 PM
From: Frederick Smart	Respond to of 42771

Paul.... >>Gotta be some serious overhead eliminated here using the Novell technology !!! Comprende? So someone lay out the processing time using NDS and XML vs using a HTML forms and CGI or whatever please. Or am I missing something entirely?>> You got it Paul. Developers I have pointed to Novell have been blown away by the ease of use and fantastic, ground breaking potential of this stuff.

To: Paul Fiondella who wrote (27248)	6/28/1999 2:12:00 AM
From: Scott C. Lemon	Read Replies (2) \| Respond to of 42771

Hello Paul, It's great to see you back posting here ... not that everyone else isn't adding great contributions! I'm going to try and address a couple of the technical issues with your post ... > Can you lay out (or anyone for that matter) the processing steps > one must take to access a non-NDS enabled Oracle database over the > web vs an NDS enabled Oracle database. Most of the "access" is going to be identical. It's managing the rights and permissions that is the biggest gains here. In the non-NDS environment, the Admin must grant people various rights to the databases and table (read, write, visible, etc.) using a completely "Oracle" security database. So administration of the "network" would be done in at least two different places - the Oracle security and the "rest of the network" security. Here, the "rest of the network" would be storage, printing, etc. In the NDS-enabled Oracle, the security and control is done through NDS. Which means while I'm in one tool granting a user rights to use a particular disk for storage, and some printers, I can also grant rights to access some database tables. In both cases, accessing the database is probably through one of many database access APIs that Oracle supports. > My understanding is that if XML is used by the site to which you > want to send data, say in response to a form they would normally > put up in HTML, it isn't necessary to go through the processing > steps of converting the data you are sending into the proper > format for the database schema, XML does that for you. (This is going to over-simplify XML, but I want to get some "base foundation" understanding in place. XLM experts, please don't flame ... contribute and clarify! ;-) The real importance of XML is the ability to tag information in web pages, or that is being exchanged between computers, so that it more usable outside of the web page. For example, if you were too look at the work being done by the ECML.Org (Electronic Commerce Markup Language) you would see that they are first trying to gety people to name the fields in a web "form" with the same labels. When you are presented, in your browser, with a form to fill out, there are actually labels (hidden from your view) for each field. When you "submit" the form the web server gets your information in a format like "label=value&label=value" etc. The web server can then extract your posted information. The problem is that every vendor who builds web pages can name the fields whatever they want. So I might use "ShippingAddress" and you might use "Shipping_Address" and the next person could use "Ship_To_Address" ... each is a completely different label. So applications trying to make things easier for end-users can't know what field represents what information ... there is no "standard" ... So groups like the ECML.Org are trying to standardize these labels ... which is also known as "schema" ... this is the most important thing that is occurring right now in directories and with XML. The "schema" of all sorts of things is being negotiated and defined. XML takes this one step further and defines the format for shipping information around in a standardized "label=value" format ... > I could put my name and address into any XML compliant site's > database without knowing anything about the actual field > layout database schema etc. Is this correct? Not quite ... but close. If I sent my information to another system, and I put it in XML, and it was using a standardized schema that the receiving system understood, then it could deal with the information as it saw fit, including mapping it to a local database. > Now take a look at a NDS enabled database. My guess is that with > NDS at the site end of the pipe, you can bypass the HTML form > entirely and access the various fields in the database as > permissioned objects --- you get access to that database and those > fields to which you are entitled. So with NDS we are in effect > sending a database record key with attached XML compliant data > packets to fill out the fields around the net rather than > HTML forms with embedded interpreter processing commands. Gotta be > some serious overhead eliminated here using the Novell technology > !!! I would have to think this through and see if I could see where any performance gains would be. The biggest is in administration and better security. NDS access control is potentially easier to understand, hence better security. > Comprende? > > So someone lay out the processing time using NDS and XML vs using a > HTML forms and CGI or whatever please. XML is not a silver bullet ... there are still issues that must be agreed upon for systems to exchange information. But it has started the drive to standardize "schema" which is the naming systems for information. This is going to drive more interoperability ... > Or am I missing something entirely? Nope ... you're on the right track! ;-) Scott C. Lemon

To: Paul Fiondella who wrote (27248)	6/28/1999 9:10:00 AM
From: PJ Strifas	Read Replies (1) \| Respond to of 42771

Hello Paul! First let me say it's very good to see you around again! Now, my knowledge of programming is limited to what I have read and seen demonstrated to me but your question entices me to hunt out some friends and ask some very pointed questions. I've already printed out your post as part of that Q&A. From what I understand, data entering a database needs to be structured in some way, shape or form to match the record fields one creates in the database. In current HTML forms, CGI or Perl scripts retrieve the data and parse that information into the correct format for input into a database via ODBC (or like technology). You are correct there is substantial overhead in this setup. XML is a HUGE step forward for websites in that it allows you to specific data using HTML-like tags. I'm sure we are all familiar with how HTML uses "tags" to define presentation guidelines for page layout and content control. XML works in the same fashion only it allows you to extend HTML to include non-traditional data formats. I've often used the example of ITEM, PRICE and QUANTITY. For example, at Amazon.com they sell books. These books have certain generic characteristics. Currently there isn't much you can do to define those characteristics on a webpage and manage that information accordingly. XML will allow you to create data types for things like HARDCOVER/PAPERBACK, ISBN Number, AUTHOR, PRICE etc. We can then use these data types to define the BOOK. Why you may ask do we need to do this? Well in the first place it would become increasing easier to search for books by author without having to invest and maintain a search engine onsite. Second, by defining BOOKS by their characteristics we gain more control over the layout, design and ease of use parameters of the website. Now this example can be applied to any and all types of websites. For the end user, this all makes for a more enjoyable website experience. Now apply this to a business-to-business website and the possibilities are endless. You can define any item in your inventory without having to wade through the process of web standards. So in this case, XML can greatly increase the performance of your website and lessen the overhead of scripts. Basically XML can preformat your data eliminating the extra processing step(s) needed currently. Also, with XML you can restructure your data without have to re-engineer your website completely. You accomplish this by re-defining your data "tags" and changing your database tables. I could go on but like I said, I have a basic understanding of how this works. Any real hardcore programmers could probably write a whole lot more. PJ Strifas