XML, RDF and I.
In my humble blog, I roughly described my attitude to XML-based languages and DOM. In short, after almost a year of working with them on the web, I came to some conclusions. In particular, that the DOM to display the complex content of a web page fits perfectly, but the XML from which this model is built is in itself too complex and redundant. Based on these notes , I think this is not only me, 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 the inefficiency of XML-like languages in the matter of data presentation. This topic intersects tightly 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, JSON-hash, or banal JavaScript with map coordinates, names, addresses, and other information. Live examples can be seen on http://mirtesen.ru/ (JSON is used here) or on http://adresa.yandex.ru/ (and here is JavaScript)
')
All this works fine, while we have a few records. But if the number of records becomes large, we spend time first on downloading the file, and then on interpreting it. The problem with both JSON and XML is that they must be fully loaded before they can be validated so that the browser correctly parses and uses them for its intended purpose. With a loaded JavaScript, the situation is somewhat more optimistic, since each subsequent function call does not depend on the previous ones and, in theory, can be executed at the moment the file is transferred, without waiting for it to finish. But, you see, this method is completely inelegant, and requires a lot of extra gestures. 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 it is.
When 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 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 completely, draw them completely, get the second twenty, draw them. And so long as we do not draw all the records. Not bad? Not really. The more information we need to display - worse we get situation.Why? I'll try to explain with examples.
Plain XML tree
as follows:
Perhaps I have made it too complicated, but it seems to me that it will better convey my thought. (I ask you in advance to forgive me for possible mistakes and errors. I have not used RDF in practice yet. Instead, I have a poorly self-written function, which cannot be compared to the syntax of the third notation but it uses the same ideas.) RDF notation :
Or, if you write more succinctly:
You can also look at other examples of the syntax of the third notation in order to make sure that I am not deceiving you or to learn something for myself.
I want to note that there is no mention of the root element in the record, without which no XML file can do. On a more concise syntax, you can probably ignore it. 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 became a bit more readable, located differently, well, that's all. But no. Unique element names allow us to do one focus - we can now sort the whole expression in the order we need. For example:
What gives us a similar feint ears? Almost nothing when using it with small amounts of data. But if there is a lot of data, then the web application (on the example of the same card with labels) starts to behave differently. Instead of displaying label by label, as in the case of loading data using JSON or XML? it gets the opportunity to first draw all the tags, attach events to them and allocate memory space for other data, and then gradually fill them with data. Show names, then descriptions, then upload pictures ... the list goes on. At the same time, no one bothers the web application to force data retrieval 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 first. If we interpolate a similar example for a large, real-world application, we will see an opportunity to get consistent detailing for almost any task — the user can start interacting with the web application, without waiting for the final data download. And at the same time continue the interaction, without requesting data for every other person. Not bad, right?
To those whom I did not convince of all the charm of such chips, I will give a couple more reasons. Firstly, despite the fact that such a system can be fully implemented without introducing any RDFs, you still have to use either the scripts in the server response to emulate something like this, or make several consecutive requests. Secondly, the RDF syntax is very similar to outputting results from databases and allows you not to be attached to the context. In practice, this may give rise to such a situation that the results of the first query will already be processed in the browser, while the last query to the database has not yet completed its execution. Isn't that pretty?
Threat If I am not right in anything - correct me, I will be grateful.
ZYY and the original is here
About RDF, I may write later. Now I want to focus more on the idea of the inefficiency of XML-like languages in the matter of data presentation. This topic intersects tightly 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, JSON-hash, or banal JavaScript with map coordinates, names, addresses, and other information. Live examples can be seen on http://mirtesen.ru/ (JSON is used here) or on http://adresa.yandex.ru/ (and here is JavaScript)
')
All this works fine, while we have a few records. But if the number of records becomes large, we spend time first on downloading the file, and then on interpreting it. The problem with both JSON and XML is that they must be fully loaded before they can be validated so that the browser correctly parses and uses them for its intended purpose. With a loaded JavaScript, the situation is somewhat more optimistic, since each subsequent function call does not depend on the previous ones and, in theory, can be executed at the moment the file is transferred, without waiting for it to finish. But, you see, this method is completely inelegant, and requires a lot of extra gestures. 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 it is.
When 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 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 completely, draw them completely, get the second twenty, draw them. And so long as we do not draw all the records. Not bad? Not really. The more information we need to display - worse we get situation.Why? I'll try to explain with examples.
Plain XML tree
as follows:
<root> <element> <parameter> <name> ID </ name> <value> 1 </ value> </ parameter> <parameter> <name> Title </ name> <value> First element </ value> </ parameter> <parameter> <name> Xcoord </ name> <value> 100 </ value> </ parameter> <parameter> <name> Ycoord </ name> <value> 100 </ value> </ parameter> <parameter> <name> Description </ name> <value> <! [CDATA [...]]> </ value> </ parameter> ... </ element> <element> <parameter> <name> ID </ name> <value> 2 </ value> </ parameter> <parameter> <name> Title </ name> <value> Second element </ value> </ parameter> ... </ element> <element> ... </ element> ... </ root>
Perhaps I have made it too complicated, but it seems to me that it will better convey my thought. (I ask you in advance to forgive me for possible mistakes and errors. I have not used RDF in practice yet. Instead, I have a poorly self-written function, which cannot be compared to the syntax of the third notation but it uses the same ideas.) RDF notation :
@prefix: <#>. : element_1 a: Element. : element_1: ID 1. : element_1: Title "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, if you 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 am not deceiving you or to learn something for myself.
I want to note that there is no mention of the root element in the record, without which no XML file can do. On a more concise syntax, you can probably ignore it. 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 became a bit more readable, located differently, well, that's all. But no. Unique element names allow us to do one focus - we can now sort the whole 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 "First element". : element_2: Title "Second element". : element_3: Title "Third Element". ... : element_1: Description "...". : element_2: Description "...". : element_3: Description "...". ...
What gives us a similar feint ears? Almost nothing when using it with small amounts of data. But if there is a lot of data, then the web application (on the example of the same card with labels) starts to behave differently. Instead of displaying label by label, as in the case of loading data using JSON or XML? it gets the opportunity to first draw all the tags, attach events to them and allocate memory space for other data, and then gradually fill them with data. Show names, then descriptions, then upload pictures ... the list goes on. At the same time, no one bothers the web application to force data retrieval 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 first. If we interpolate a similar example for a large, real-world application, we will see an opportunity to get consistent detailing for almost any task — the user can start interacting with the web application, without waiting for the final data download. And at the same time continue the interaction, without requesting data for every other person. Not bad, right?
To those whom I did not convince of all the charm of such chips, I will give a couple more reasons. Firstly, despite the fact that such a system can be fully implemented without introducing any RDFs, you still have to use either the scripts in the server response to emulate something like this, or make several consecutive requests. Secondly, the RDF syntax is very similar to outputting results from databases and allows you not to be attached to the context. In practice, this may give rise to such a situation that the results of the first query will already be processed in the browser, while the last query to the database has not yet completed its execution. Isn't that pretty?
Threat If I am not right in anything - correct me, I will be grateful.
ZYY and the original is here
Source: https://habr.com/ru/post/18047/
All Articles