Cart
[Home] [By Thread] [By Date] [Recent Entries]
Some thoughts... 1.) "Kerry also plans to parse each document as it arrives, but because the documents are RDF, the information can be stored in a triple store, which may be implemented in a relational database. Kerry doesn't need to define the tables to store the information items because the RDF model dictates how the data is to be represented." So a benefit of the RDF solution is that instead of leveaging existing investements in relational data stores that are common place in the enterprise one can use a different, potentially incompatible data store? Have you missed the occurences within the database world in the past few years with regards to Object Oriented Databases and Native XML databases? This should be taken to heart whenever one touts some new data storage technology as a replacement for relational stores. 2.) "A lot of Sam's time is spent writing code that stores the context of the current element in the SAX stream so the various prices can be disambiguated. Another large chunk of time is spent writing SQL to store the various information items to the correct tables in the database. Once this work has been completed, Sam can move onto writing more SQL to query the database in order to produce a list of products that the customer wants to buy." Or he could just define a mapping between the input XML and his relational tables using a number of XML mapping technologies that target his database of choice. For instance if he was a user Microsoft's SQL Server 2000 this could easily be handled by SQLXML (http://msdn.microsoft.com/sqlxml). Also in we are close to having the major relational databases providing native XML storage and query which makes this point moot. 3.) "The next week, Sam is presented with the XML schema for the invoices the company plans to send out. Sam reads through the schema and notes that there are small inconsistencies with the purchase order schema. For example, this schema uses attributes for the customer number whereas the previous schema used elements. Sam realises that there isn't going to be much reuse of the code that was written for parsing the purchase orders. In fact, Sam ends up writing a completely new SAX reader for the invoice format, plus another chunk of invoice-specific SQL and database code. Sam also discovers that products can have discounts for bulk orders and has to change the database schema to account for this. Sam ends up re-writing the purchase order query as well to ensure that the prices are being pulled from the new table. " XSLT is your friend. Soon we'll have XQuery and this will be even more of a moot point. -- PITHY WORDS OF WISDOM The other line always moves faster. This posting is provided "AS IS" with no warranties, and confers no rights. > > > -----Original Message----- > From: Ian Davis [mailto:iand@i...] > Sent: Thursday, April 24, 2003 7:42 AM > To: xml-dev@l... > > Hello all, > > I've written an article called 'RDF for Modular, Extensible Markup': > > "XML provides extensibility through a common syntax but leaves the > interpretation of the information to the developer. Increasing > modularity through the use of XML namespaces further increases > developers' workload as they struggle to interpret ever more > complex data models. RDF leverages the syntactic extensibility of > XML and the modularity of XML namespaces and additionally provides > global extensibility through a common data model." > > http://www.semanticplanet.com/2003/04/rdfForModularExtensibleM arkup.html Any comments are very welcome. - Ian <iand@i...> "Never discourage anyone...who continually makes progress, no matter how slow." ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://lists.xml.org/ob/adm.pl>
|
