Kevin Williams

Greenhorn
+ Follow
since Jan 03, 2001
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Kevin Williams

Ram,
The obvious ones are SQL Server 2000, Oracle... er... 8, I think (you might have to download some extra libraries - I'm not an Oracle DBA, so I'm not sure), and XML-native databases like Tamino. I also think that some of the open-source platforms (like MySQL) are working on XML-enabling their output.
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
Shantanu,
You can't really do this, since HTML processors deal with images as separate streamed entities that are returned in a second pass. Probably the best approach would be to write a servlet that takes some sort of key, retrieves the image from the database corresponding to that key, and streams it back to the client; you would then send a URL pointing to that servlet (and passing it the appropriate key) as the HREF attribute on the IMG element in your HTML document.
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
I've really only been able to think of one situation where browser-side transformation makes sense, and that's when there's a set of data that the client may wish to view different ways. Since the browser will (should) cache the XML document when it comes down, displaying a different view of that data would only require a download of a new stylesheet, rather than requiring the entire data set to be downloaded again. In my opinion, the "native" support for XML in IE5 is just a toy, really - to move any usable content to a client, it ultimately needs to wind up in some rich presentation format the client understands, such as HTML or WML. And, as Frank says, this is typically done by styling the XML on the server with an XSLT stylesheet.
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
Again, Ajith has this right. The greatest gains you'll realize for a B2B portal will be on the server side, allowing you to transfer information between your various customers in a consistent and logical way. XML is also very good for making your presentation layer portable - allowing you to support wireless devices, for example - but that's typically more of a B2C or C2C thing rather than a B2B.
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
Ajith's right - XML won't let you get to a database directly. In my book, though, I provide some ways you can transform relational data into XML data and vice-versa, so that you can use your relational data to drive a presentation layer via XSLT or transmit your relational data to another company.
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
The biggest problem most developers encounter when they start trying to create XSLT stylesheets is that XSLT is a declarative language, not a procedural one. This means that constructs that look like looping constructs, such as xsl:for-each, don't behave in the way you might expect. For example, if I want to use an xsl:for-each loop to select some distinct subset of elements, I can't use a variable to "remember" what the previous iteration's node value was - as that won't be available when the "next" matched element is processed. I also find the available constructs in XSLT somewhat limiting - certain sophisticated operations, such as taking the weighted average of one value across another value over some set of elements, can't be done using XSLT (at least not in one pass).
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
Brian,
I know the kind of legacy client you're talking about - it's the same kind of client that used to say "Oh, COBOL's not going anywhere - we're going to be using our dumb terminals and CICS screens for the foreseeable future." Certainly many large corporations have invested an incredible amount of money in their EDI infrastructure, so they're going to be loath to discard it in favor of XML. However, there are some serious limitations with EDI which I think many corporations are coming to recognize. I did some work on the MISMO XML standard for the mortgage industry, which of course is very old-school and relies heavily on EDI - but the big players in that industry recognize the advantages of XML over EDI. The flexibility of XML standards, the human-readability of XML documents, and the emergent transport standards and tools to manipulate XML have all combined to make it a very attractive alternative to EDI. I think that XML standards will ultimately supplant EDI - it may just be a slower process in some corporate circles.
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
Greg,
This one threw me the first time I ran into it too. UTF-8, as it turns out, only covers the lower 128 of the ASCII character set - in other words, the section of the 256-character ASCII set you're probably more familiar with that contains all the accented, umlauted, and so on characters is not part of UTF-8. The two encodings that every parser is obligated to recognize are UTF-8 and UTF-16 (Unicode), so if you want to use UTF-16 you should be all right.
BTW, somebody correct me if I'm misspeaking here - it's been a while since I've done any international stuff...
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
These days, most parsers contain (conveniently enough) both SAX and DOM interfaces - so that shouldn't be an issue. Right now, based on the conversations I've been having with others in the industry, the emergent parsers seem to be MSXML (on the Microsoft platform) and JAXP (on the Java platform).
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
Russ,
Whether or not you should use a standard is entirely dependent on your needs and the requirements of any systems that will produce or consume the documents you're trying to define. If you're creating a structure that will only be used internally, then (as Ray says) you're better off building one from scratch or modifying an existing standard that's out there. If you need to communicate with other systems, then the problem is a little trickier - you need to make sure that all of the systems in the audience for the document agree on what that document needs to contain.
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
Ray,
XML doesn't provide "database connectivity" per se - it's only a way of representing data in a structured form. However, the most important thing that XML does provide is the ability to separate content from display - so you could use Java to create XML from relational data (or use Oracle or SQL Server's built-in XML creation functionality), and then use XSLT to transform the XML into whatever format you wanted (HTML, WML, and so on).
Does that answer your question?
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
Frank's right - I should have been more clear with what I said. In most instances, an indexed XML document store is the best way to go.
With regards to your question, Colin, it depends on the type of information you're trying to retrieve. If you are trying to select 4000 records out of a million, then a relational database would be the best way to go. On the other hand, if you have the 4000 records in one place (an XML document), it'll be easier to manipulate that document directly than it would be to call into a relational database to return the data. It all depends on the situation.
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
Holger's response makes a good point. For the sake of reusability and modularity, I always try to use the xsl: methods to create elements, text, and so on, rather than simply embedding the tags and text in the stylesheet. This makes it much easier to modify the stylesheet later if you need to. Also, certain types of structures (like attributes) can only be created this way.
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
As a good rule of thumb, I design my XML and relational databases this way:
If I need to search data or aggregate it (perform computations across multiple records like sums or averages), I store it in a relational database. That's what relational databases are best at.
If I need to transform information into a different format for display purposes (to support both HTML and wireless devices, for example) or I need to transmit information across the Internet (to a business partner, perhaps) then I use XML. Those are two of the things that XML is good at.
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases
I think that, from everything I've seen, Microsoft is going to be much more of a team player with regards to XML than it has been with other platforms (J++, anyone?) in the past. They have stated openly that XML will be the backbone of their future products, including their .NET software development suite. They've been part of the development of XML almost since the beginning, and I think they're not going to try to come up with their own version anytime soon.
- Kevin
------------------
Kevin Williams
Senior System Architect, Equient Corporation
author of: Professional XML Databases