December 26, 2007 at 06:03XML, RDF, and I.
In my humble blog, I roughly outlined my attitude to XML-based languages and the DOM. In short, after almost a year of working with them on the web, I came to some conclusions. In particular, the DOM is ideal for displaying the complex content of a web page, but the XML from which this model is built is itself too complex and redundant. Based on such notes , not only I think so, but also other developers, as well as the great and terrible W3C itself .
About RDF, I may write later. Now I want to focus more on the idea of inefficiency of XML-like languages in the issue of data representation. This topic intersects closely with the benefits of RDF. Therefore, as I think, this note can be considered an illustration of its use.
Let's start with a simple example. Map with addresses. There is nothing complicated about it.
The standard implementation is either an XML tree, a JSON hash, or commonplace JavaScript with coordinates on the map, names, addresses, and other information. Live examples can be seen on http://mirtesen.ru/ (here JSON is used) or on http://adresa.yandex.ru/ (and here JavaScript).
All this works great while we have a few records. But if the number of records becomes large, we spend time first downloading the file, and then interpreting it. The problem with both JSON and XML is that they must be fully loadedbefore they can be validated so that the browser correctly parses them and uses them for their intended purpose. With the loaded JavaScript, the situation is somewhat rosy, since each subsequent function call does not depend on the previous ones and, in theory, can be executed at the moment the file is being transferred, without waiting for its completion. But, you must admit, this method is completely inexhaustible, and requires a lot of extra body movements. Although, it is worth noting, it is now the only one that can be used to solve such problems. At least according to my information, this is so.
At the DOM level, we can easily process the incoming data stream, generating their display right during the transfer. The only thing that bothers us is the inability to read the server response line by line :(. But this costs an increase in the number of consecutive requests. (First, we get the first 20 records, then we get the records from the 21st to the 40th, etc.). Common data transfer formats coping with this task is not so bad: we get the first twenty records in full, draw them completely, get the second twenty, draw them. And so until we depict all the records. Not bad? Not really. The more information we need to display, the worse we get I’ll try to explain with examples, a
regular XML tree
looks like this:
Maybe I overcomplicated it, but it seems to me that it will convey my idea better. (I ask you to forgive me in advance for possible mistakes and mistakes. I have not used RDF in practice yet. Instead, I have a miserable self-written function that, by its conciseness, cannot be compared with the syntax of the third notation, but uses similar ideas.) Now, we will translate it into the third RDF notation :
Or, to write more succinctly:
You can also look at other examples of the syntax of the third notation , in order to make sure that I do not deceive you or draw something for myself.
I want to note that the record does not mention the root element, without which no XML file can do. You can probably ignore the more concise syntax. If desired, XML can also be tamped. One of the differences is the unique name of the elements. This is important, despite the fact that at first glance there are no fundamental differences. Well, maybe it has become a little more readable, arranged differently, and that’s all. But no. Unique element names allow us to do one focus - we can now sort the entire expression in the order we need. For example:
What gives us a similar feint with ears? Almost nothing when using it with small amounts of data. But if there is a lot of data, then the web application (using the same map with tags as an example) starts to behave differently. Instead of displaying label by label completely, as in the case of loading data using JSON or XML? it gets the opportunity to first draw all the labels, bind events to them and allocate memory space for other data, and then gradually fill them with data. Show titles, then descriptions, and then upload pictures ... the list goes on and on. In this case, no one bothers to force the web application to receive data on an arbitrary object, if the user has shown interest in it by requesting data on a specific element in the second stream, because the ID is loaded with us first.consistent detailing for almost any task - the user can begin to interact with the web application without waiting for the final data download. And at the same time continue to interact without requesting data for each sneeze. Not bad, is it?
Those whom I have not convinced in all the charm of such chips, I will give a couple more reasons. Firstly, despite the fact that such a system could well be implemented without introducing any RDFs, you still have to use either scripts in the server’s response to emulate something like this, or make several consecutive requests. Secondly, the RDF syntax is very similar to the output of the result from the database and allows you not to get attached to the context. In practice, this can give rise to a situation where the results of the first query will already be processed in the browser, until the last query to the database has not yet completed its execution. Isn't it pretty?
PS If I'm wrong about something - correct me, I will be grateful.
ZYY and the original lies here
About RDF, I may write later. Now I want to focus more on the idea of inefficiency of XML-like languages in the issue of data representation. This topic intersects closely with the benefits of RDF. Therefore, as I think, this note can be considered an illustration of its use.
Let's start with a simple example. Map with addresses. There is nothing complicated about it.
The standard implementation is either an XML tree, a JSON hash, or commonplace JavaScript with coordinates on the map, names, addresses, and other information. Live examples can be seen on http://mirtesen.ru/ (here JSON is used) or on http://adresa.yandex.ru/ (and here JavaScript).
All this works great while we have a few records. But if the number of records becomes large, we spend time first downloading the file, and then interpreting it. The problem with both JSON and XML is that they must be fully loadedbefore they can be validated so that the browser correctly parses them and uses them for their intended purpose. With the loaded JavaScript, the situation is somewhat rosy, since each subsequent function call does not depend on the previous ones and, in theory, can be executed at the moment the file is being transferred, without waiting for its completion. But, you must admit, this method is completely inexhaustible, and requires a lot of extra body movements. Although, it is worth noting, it is now the only one that can be used to solve such problems. At least according to my information, this is so.
At the DOM level, we can easily process the incoming data stream, generating their display right during the transfer. The only thing that bothers us is the inability to read the server response line by line :(. But this costs an increase in the number of consecutive requests. (First, we get the first 20 records, then we get the records from the 21st to the 40th, etc.). Common data transfer formats coping with this task is not so bad: we get the first twenty records in full, draw them completely, get the second twenty, draw them. And so until we depict all the records. Not bad? Not really. The more information we need to display, the worse we get I’ll try to explain with examples, a
regular XML tree
looks like this:
ID 1 Title First element Xcoord 100 Ycoord 100 ... Description ID 2 ... Title Second element ... ...
Maybe I overcomplicated it, but it seems to me that it will convey my idea better. (I ask you to forgive me in advance for possible mistakes and mistakes. I have not used RDF in practice yet. Instead, I have a miserable self-written function that, by its conciseness, cannot be compared with the syntax of the third notation, but uses similar ideas.) Now, we will translate it into the third RDF notation :
@prefix: <#>. : element_1 a: Element. : element_1: ID 1. : element_1: Title "The first element." : element_1: Xcoord 100. : element_1: Ycoord 100. : element_1: Description "...". : element_2 a: Element : element_2: ID 2. : element_2: Title "Second element". ... : element_3 a: Element ...
Or, to write more succinctly:
@prefix: <#>. : element_1 a: Element; : ID 1; : Title "The first element"; : Xcoord 100; : Ycoord 100; : Ycoord 100; : Description "...". : element_2 a: Element; : ID 2; : Title "The first element"; : Xcoord 200; : Ycoord 200; : Ycoord 100; : Description "...". : element_3 a: Element; : ID 3; : Title "The first element"; : Xcoord 300; : Ycoord 300; : Ycoord 100; : Description "...".
You can also look at other examples of the syntax of the third notation , in order to make sure that I do not deceive you or draw something for myself.
I want to note that the record does not mention the root element, without which no XML file can do. You can probably ignore the more concise syntax. If desired, XML can also be tamped. One of the differences is the unique name of the elements. This is important, despite the fact that at first glance there are no fundamental differences. Well, maybe it has become a little more readable, arranged differently, and that’s all. But no. Unique element names allow us to do one focus - we can now sort the entire expression in the order we need. For example:
@prefix: <#>. : element_1 a: Element; : ID 1; : Xcoord 100; : Ycoord 100. : element_2 a: Element; : ID 2; : Xcoord 200; : Ycoord 200. : element_3 a: Element; : ID 3; : Xcoord 300; : Ycoord 300. ... : element_1: Title "The first element." : element_2: Title "Second element". : element_3: Title "The third element." ... : element_1: Description "...". : element_2: Description "...". : element_3: Description "...". ...
What gives us a similar feint with ears? Almost nothing when using it with small amounts of data. But if there is a lot of data, then the web application (using the same map with tags as an example) starts to behave differently. Instead of displaying label by label completely, as in the case of loading data using JSON or XML? it gets the opportunity to first draw all the labels, bind events to them and allocate memory space for other data, and then gradually fill them with data. Show titles, then descriptions, and then upload pictures ... the list goes on and on. In this case, no one bothers to force the web application to receive data on an arbitrary object, if the user has shown interest in it by requesting data on a specific element in the second stream, because the ID is loaded with us first.consistent detailing for almost any task - the user can begin to interact with the web application without waiting for the final data download. And at the same time continue to interact without requesting data for each sneeze. Not bad, is it?
Those whom I have not convinced in all the charm of such chips, I will give a couple more reasons. Firstly, despite the fact that such a system could well be implemented without introducing any RDFs, you still have to use either scripts in the server’s response to emulate something like this, or make several consecutive requests. Secondly, the RDF syntax is very similar to the output of the result from the database and allows you not to get attached to the context. In practice, this can give rise to a situation where the results of the first query will already be processed in the browser, until the last query to the database has not yet completed its execution. Isn't it pretty?
PS If I'm wrong about something - correct me, I will be grateful.
ZYY and the original lies here