But, I already have the code to do this...What new features can XML give me when dealing with setting information for custom apps?
There is a general principle of good practice when developing code - don't re-invent the wheel. It doesn't matter if what you have done is as good as XML for you. The point is that XML is a documented standard, and it is portable. If you had used XML for your project, that what you had done would have been easily understood and re-used, and your data would have been portable to other applications with no effort.
If you don't think there aren't many tools out there for XML, I don't think you have looked very far!
The fact that such language is used does not mean that they don't expect everyone else to follow along.
Of course they hope that people will follow, but any scientist with any experience does not 'expect' it. Science is designed to be cautious and careful about what it says.
Just look at how much influence weather-based science, which is still in its infancy, has on public policy, when it really should have very little influence at this stage in our knowledge.
Considering the dramatic reduction in thickness of the Artic ice sheet, the measurable shrinkage of glaciers and the increased frequencies of hurricanes, I think that its absolutely vital that we use whatever science we have to influence polity.
I think the problem that some of us have is that scientists expect the rest of us to take what they say as fact, when in fact, it is just the best guess they can make today.
It is exactly the reverse. In almost everything that is published scientifically, it is made abundantly clear that there is uncertainty, hence the the title of the article: 'Volcanic Warming Eyed in Great Dying' and not 'Yup, it was volcanoes that did it'.
It's very evocative. Here's this probe from one world, landing on another, and what does it see?
A shoreline!
I agree that it is a great picture, but there is no (published) evidence that this is a shoreline. The flat area could be anything - dust, mud, tar, sand. Perhaps it was once a shoreline, but is now dry.
Before we start trying to interpret these images, we should wait until the science is done.
If the shared context is read only, then ZERO concurrency management issues arise and my original comments stand.
As I said, the shared contexts of most Java server applications are not read only (see below).
Serious SMP applications have to worry about every thread altering data that any other thread might need to access. This is what separates Oracle from a glorified renderfarm.
Any thread on a web service can alter data. Even a simple commercial shopping application will need to maintain a consistent centralised record of the results of requests. Click 'add to basket', then log on on another client machine and a different request thread can pick up what you have stored. It is also common practice for such applications to log each and every page request. This means that each thread will communicate with a single logging process at some point.
Webservers and java servers don't share any common resources. Much like a renderfarm, you can split the problem onto as many single or dual cpu systems as you like with no scaling penalty.
This isn't true. Well-written server-side Java applications make a lot of use of shared resources (without this, it would not be practical to run hundreds of threads in a few GB of memory). Most of the information needed to present web pages or provide web services is placed in either application or session context, and shared between threads. This shared information is not read-only - there are processes such as user and session tracking and cookie management for example.
Web and java appservers are the IT equivalent of a renderfarm. They have no place in this discussion.
I disagree. First, the post I replied to said, about high numbers of processors that..."Both represent a scale of problem that few ever deal with." Well, web and appservers are very common!
Secondly, these types of application frequently make a lot of use of kernel services. They can require networking and/or disk activity to make use of databases or other forms of information storage, or to connect to other services in the company.
With your XML way you have no documentation directly in the file.
You mean like:
<-- This is a note about the following settings -->?
If you have a config file all settings should be documented in there and if you have a data file you should be able to have one documentation for an example entry at the beginning of the file.
I think you are missing the point. With a configuration file like this, you HAVE to have the documentation in there to interpret the settings. With XML you don't.
The "name=value" syntax is a lot easier to parse than XML and allows you to store the settings in memory in the way you want.
Why should you care how easy the file is to parse? Don't bother to parse it yourself - use an API like SAX - and then you can store the settings in whatever way you like.
Some other points:
The name=value syntax isn't portable or expandable. Suppose the name or value contains '='? You will need to define what delimiter should be used for the name and value. XML is a defined standard for delimiting values.
This syntax does not allow for trees. XML can do this.
How do you handle strings that require non-printable characters, like newlines? XML has a standard for this.
Suppose you have put in the documentation about what format is and what the parameters mean and then the software is dispatched to a foreign country? XML is an international standard.
Suppose someone else wants to add new settings to the configuration file. Will this prevent your software working? With their names of properties clash with yours? These matters are handled in XML.
Finally, there is nothing in the file that would allow any software to automatically detect that this is a name=value file. XML always starts with <?xml.
XML is an easy-to-use standard solution to these problems, with many well-supported high-quality libraries and tools to handle it. It can be as simple or complicated as you like. What is the objection?
I want to know is if there is a good reason to switch to XML with some of my new code. When there is no way in hell I am going to let people edit the data in raw format.
There are at least two good reasons that come to mind immediately:
1. Why re-invent the wheel? Using XML means that you can use high-quality tools and libraries to process and edit the configuration files.
2. Even if you are the only one using this format, XML gives you the ability to cleanly add new features and extend the format in the future, without disrupting the ability of legacy code to handle the data.
So you might as well setup a GUI to look at the data while your making your app as these are all setings that your going to need to edit anyway.
But with XML, the tools for doing this are already in existence. What is the point of doing all this yourself?
XML is not Human readable on anything ther than the most simple app.
Having used XML extensively, I would disagree with this.
And do you want people to be able to mess with config files when they don't have the documentation?
But that is exactly why XML is useful: 1. A configuration file will most likely have a DTD or schema, so that if you modify it, those modifications can be validated, as can the structure of the entire XML file. 2. XML is extensible. It is perfectly acceptable to add your own tags, which give additional meaning to the file. Tags which aren't understood by a particular application will be safely ignored. 3. XML IS human readable: Which would you feel more confident editing:
<setting type="integer">123</setting>
or
10,123
(Was the indication for integer 10? I don't remember. Someone might tell me that '10' means 'integer', but there is nothing else to indicate this)
Good XML will be self-documenting, but even bad XML is better than
0 = new tree 1 = string ASCII 2 = String Unicode 10 = signed int 20 = unsigned int 30 = floating point number (format 1) 31 = floating point number (format 2)... I basicly keep aything under 10,000 as uneversal format's and use stuff over that for odd adhock stuff which I don't have time to deconstruct.
If I had come across one of your configuration files, and did not have this key to the meaning, I would have had no idea how to interpret it.
At it's core XML is nothing. It's so generic, so basic, so flexible, whatever you want to call it, that it's completely pointless. Yes, you read that right, the structure is so flexible that it's not really structure any more.
XML is certainly NOT that generic or basic. It's strength is in its rules. These rules give it enormous power. They mean that XML is a standard. My XML reader will read your XML file. It is extensible: If I have some data I want to add to your XML file I can do that without corrupting the meaning of your file, and without messing up your software. XML is self-documenting. It is clear where data starts and stops (you may think this is obvious, but take a look at an arbitrary text data file, which may or may not have commas separating items, and might allow newlines in strings, or might not, etc.). XML is easily transformed and manipulated by software. XML is structured to allow arbitrary data to be stored.
The alternative is a mass of undocumented text or binary data files which are meaningless without external documentation or software to interpret them.
This is the real question which is oft ignored. There is far too great an emphasis of being able to manage n CPUs rather than how effectively kernel services operate on n CPUs.
Absolutely. This is why we should be wary of claims that have been made (and posted on Slashdot recently) that Linux 'scales to 512 or 1024 processors' (as in some SGI machines). This size of machine is only effective for very specialised software. A report that the kernel scales well to 64 processors is far more believable, and is a sign of the increasing quality of Linux.
The grandparent poster said that Linux had supported systems for longer and cheaper than Windows.
No it didn't. Read it again. It said Linux distributions generally provide much longer (and cheaper) support for older versions of the OS.
It said 'provide', not 'had provided'. You got the tense wrong. It's an on-going thing. For example, Debian provide resources for a smooth (free) updating of any earlier version to any required current version. There is no plan to stop this. Even if this did not go back to versions from a long time ago (it does) this would still be longer support than for Windows, as Microsoft products have limited support periods.
Fedora hasn't been around since NT4. The grandparent poster said that Linux had supported systems for longer and cheaper than Windows. My question was what Linux?
Both Debian (1995) and Slackware (1993-1994) distributions have been around, and have provided free upgrades, since before NT4 (1996).
But of course, this is irrelevant. The point is that distributions like these have no support time limits. They plan to provide free support and upgrades indefinitely. This is obviously not the case with Windows - there will always come a point at which a full upgrade to a new OS is required.
About number 2, nobody is forcing companies to buy new hardware or go with the latest OS. Many companies have stuck with NT4, or even 2000.
If they stick with these systems they lose support, which includes patches for major security issues. Linux distributions generally provide much longer (and cheaper) support for older versions of the OS.
By the way... thanks for a stimulating discussion!
You start with our own Universe
I disagree. Many models of universes start with assumptions which may, or may not, have anything to do with our universe (holographic models, string theory etc.). We don't know. They are just models. As we don't even know what our universe is, how can our models be based on it?
"Random" is not an explanation. It is merely a statement that an explanation is not possible given the information available. That is, you've figured out the how, but you can't figure out the why.
I would say that it is a statement that there is no necessity to figure out the 'why'. I would say that it means there IS no why! Anyone looking for a 'why' is wasting their time.
It's a postulate, and that's the point. Both the postulate "God created the Universe" and "The Universe evolved randomly to where it is" lead to the exact same Universe we have to day - either by God's choice, or the weak anthropic principle.
Yes, so why even bother with the more complicated (God) postulate? It serves no purpose. If you say 'God created the Universe', you might as well say 'two Gods created the Universe' etc, and so on. Best stick with the simplest option.
You're not adding any factors into any hypothesis you make regarding how the person acts.
That's not what I was saying. What I meant was that adding 'will' added complexity to the whole situation, not just why something happens.
(Personally, I believe that there are good philosophical reasons to believe that will DOES change how a person acts).
Let's face it - a cold turkey jump to OSS is damn difficult for any company.
Is it? I have done this several times. It really is no more trouble for end users than a switch from, say, win98 to XP. With good sysadmins, it can be a very smooth transition.
When you're creating relations between tables, a graphical table editor and a GUI that lays everything out for you is pretty nice and takes away alot of the eliteness of the DB world. I can get a moderately experienced office worker setup with Access very quickly, but using MySQL requires more experience.
If you install the JDBC driver, current versions (1.1.x) of Open Office does all this very nicely, and includes the ability to design forms and run mail merges.
Why would they do that ? MS Windows is free (as in "the PC isn't sold cheaper without it"), and can run Evolution, Firefox, OpenOffice.org, and basically every other program which would make Linux a better choice. Where is the incentive ?
1. Virus resistance. This can be a major advantage and time-saver in a large organisation.
2. No forced software and hardware update cycles.
3. Very easy remote support. Secure remote X11 access is either the default on Linux, or at least is simple to set up.
4. Versatility. Linux workstations are fully licensed to act as servers if the need arises.
5. Security. Linux workstations are by default set up with separate administrator accounts, and so the ability of users to mess about with their own machines (such as installing pirate software) is limited.
6. Often the PC IS sold cheaper without it! I can buy PCs installed with whatever Lindows is called now, and there is a significant saving.
Nah, that's just ways to discover more about our own current Universe, because the modeling is based upon the rules of our own Universe. It's a self-consistency check. In other words, we're making mathematical models of modified versions of our own Universe. Not new Universes altogether.
I have to disagree. Some of these models have nothing whatsoever to do with our universe (such as those with additional time dimensions).
I'm not talking about an intelligence, I'm talking about a will. Wills aren't complex or simple. They just are. This isn't an Occam's Razor issue in the tiniest bit.
It is, as having a will is more complex than not having a will - it's adding another factor.
The point that I'm making is that clues regarding a creator must be explainable via other methods. In other words, you can say "they're not clues", and I can say "they are clues", and we'd both be right.
No, as calling these 'clues' is to make a whole load of assumptions. It's not up to me to prove that they are not clues - it's up to you to prove they are. Having no assumptions is simpler.
Both viewpoints are equally, unprovably, correct. "Random" implies a point of view.
They are unprovable, but one is more sensible. If something can be explained by randomness, there is no need for another explanation. To add further explanation is to complicate things and requires a lot of work to prove.
Slashdot Mirror
But, I already have the code to do this ...What new features can XML give me when dealing with setting information for custom apps?
There is a general principle of good practice when developing code - don't re-invent the wheel. It doesn't matter if what you have done is as good as XML for you. The point is that XML is a documented standard, and it is portable. If you had used XML for your project, that what you had done would have been easily understood and re-used, and your data would have been portable to other applications with no effort.
If you don't think there aren't many tools out there for XML, I don't think you have looked very far!
"Nothing we know of zips along more quickly than light. Einstein, nearly 100 years ago, said it's not possible."
Erm did'nt he say nothing(matter) can accelerate to the speed of light?
True, and also nothing that has mass can decelerate to the speed of light.
You can have tachyons (faster) and 'tardyons' (slower).
The fact that such language is used does not mean that they don't expect everyone else to follow along.
Of course they hope that people will follow, but any scientist with any experience does not 'expect' it. Science is designed to be cautious and careful about what it says.
Just look at how much influence weather-based science, which is still in its infancy, has on public policy, when it really should have very little influence at this stage in our knowledge.
Considering the dramatic reduction in thickness of the Artic ice sheet, the measurable shrinkage of glaciers and the increased frequencies of hurricanes, I think that its absolutely vital that we use whatever science we have to influence polity.
I think the problem that some of us have is that scientists expect the rest of us to take what they say as fact, when in fact, it is just the best guess they can make today.
It is exactly the reverse. In almost everything that is published scientifically, it is made abundantly clear that there is uncertainty, hence the the title of the article: 'Volcanic Warming Eyed in Great Dying' and not 'Yup, it was volcanoes that did it'.
It's very evocative. Here's this probe from one world, landing on another, and what does it see?
A shoreline!
I agree that it is a great picture, but there is no (published) evidence that this is a shoreline. The flat area could be anything - dust, mud, tar, sand. Perhaps it was once a shoreline, but is now dry.
Before we start trying to interpret these images, we should wait until the science is done.
If the shared context is read only, then ZERO concurrency management issues arise and my original comments stand.
As I said, the shared contexts of most Java server applications are not read only (see below).
Serious SMP applications have to worry about every thread altering data that any other thread might need to access. This is what separates Oracle from a glorified renderfarm.
Any thread on a web service can alter data. Even a simple commercial shopping application will need to maintain a consistent centralised record of the results of requests. Click 'add to basket', then log on on another client machine and a different request thread can pick up what you have stored. It is also common practice for such applications to log each and every page request. This means that each thread will communicate with a single logging process at some point.
Webservers and java servers don't share any common resources. Much like a renderfarm, you can split the problem onto as many single or dual cpu systems as you like with no scaling penalty.
This isn't true. Well-written server-side Java applications make a lot of use of shared resources (without this, it would not be practical to run hundreds of threads in a few GB of memory). Most of the information needed to present web pages or provide web services is placed in either application or session context, and shared between threads. This shared information is not read-only - there are processes such as user and session tracking and cookie management for example.
Web and java appservers are the IT equivalent of a renderfarm. They have no place in this discussion.
I disagree. First, the post I replied to said, about high numbers of processors that..."Both represent a scale of problem that few ever deal with." Well, web and appservers are very common!
Secondly, these types of application frequently make a lot of use of kernel services. They can require networking and/or disk activity to make use of databases or other forms of information storage, or to connect to other services in the company.
A claim that Linux scales well to 64 cpus is no
more or less believable than a claim that it scales
to 1024.
Surely the lesser number is more believable!
Both represent a scale of problem that few ever deal with.
Large businesses like large numbers of processors. Some software scales naturally to this kind of setup: web and application servers, for example.
With your XML way you have no documentation directly in the file.
You mean like:
<-- This is a note about the following settings -->?
If you have a config file all settings should be documented in there and if you have a data file you should be able to have one documentation for an example entry at the beginning of the file.
I think you are missing the point. With a configuration file like this, you HAVE to have the documentation in there to interpret the settings. With XML you don't.
The "name=value" syntax is a lot easier to parse than XML and allows you to store the settings in memory in the way you want.
Why should you care how easy the file is to parse? Don't bother to parse it yourself - use an API like SAX - and then you can store the settings in whatever way you like.
Some other points:
The name=value syntax isn't portable or expandable. Suppose the name or value contains '='? You will need to define what delimiter should be used for the name and value. XML is a defined standard for delimiting values.
This syntax does not allow for trees. XML can do this.
How do you handle strings that require non-printable characters, like newlines? XML has a standard for this.
Suppose you have put in the documentation about what format is and what the parameters mean and then the software is dispatched to a foreign country? XML is an international standard.
Suppose someone else wants to add new settings to the configuration file. Will this prevent your software working? With their names of properties clash with yours? These matters are handled in XML.
Finally, there is nothing in the file that would allow any software to automatically detect that this is a name=value file. XML always starts with <?xml.
XML is an easy-to-use standard solution to these problems, with many well-supported high-quality libraries and tools to handle it. It can be as simple or complicated as you like. What is the objection?
I want to know is if there is a good reason to switch to XML with some of my new code. When there is no way in hell I am going to let people edit the data in raw format.
There are at least two good reasons that come to mind immediately:
1. Why re-invent the wheel? Using XML means that you can use high-quality tools and libraries to process and edit the configuration files.
2. Even if you are the only one using this format, XML gives you the ability to cleanly add new features and extend the format in the future, without disrupting the ability of legacy code to handle the data.
So you might as well setup a GUI to look at the data while your making your app as these are all setings that your going to need to edit anyway.
But with XML, the tools for doing this are already in existence. What is the point of doing all this yourself?
XML is not Human readable on anything ther than the most simple app.
Having used XML extensively, I would disagree with this.
And do you want people to be able to mess with config files when they don't have the documentation?
But that is exactly why XML is useful:
1. A configuration file will most likely have a DTD or schema, so that if you modify it, those modifications can be validated, as can the structure of the entire XML file.
2. XML is extensible. It is perfectly acceptable to add your own tags, which give additional meaning to the file. Tags which aren't understood by a particular application will be safely ignored.
3. XML IS human readable: Which would you feel more confident editing:
<setting type="integer">123</setting>
or
10,123
(Was the indication for integer 10? I don't remember. Someone might tell me that '10' means 'integer', but there is nothing else to indicate this)
Good XML will be self-documenting, but even bad XML is better than
10,123
0 = new tree ...
1 = string ASCII
2 = String Unicode
10 = signed int
20 = unsigned int
30 = floating point number (format 1) 31 = floating point number (format 2)
I basicly keep aything under 10,000 as uneversal format's and use stuff over that for odd adhock stuff which I don't have time to deconstruct.
If I had come across one of your configuration files, and did not have this key to the meaning, I would have had no idea how to interpret it.
This is exactly the argument for using XML.
Your TCP/IP packets don't all start and end with < and >, and they seem to be fairly portable.
Not beyond TCP/IP! They are of no use on a IPX or SMB network.
Endian-ness and packing are not rocket science.
Right, so I give you an arbitrary binary data file, and you tell me the endian-ness without having access to the software that can read it.
At it's core XML is nothing. It's so generic, so basic, so flexible, whatever you want to call it, that it's completely pointless. Yes, you read that right, the structure is so flexible that it's not really structure any more.
XML is certainly NOT that generic or basic. It's strength is in its rules. These rules give it enormous power. They mean that XML is a standard. My XML reader will read your XML file. It is extensible: If I have some data I want to add to your XML file I can do that without corrupting the meaning of your file, and without messing up your software. XML is self-documenting. It is clear where data starts and stops (you may think this is obvious, but take a look at an arbitrary text data file, which may or may not have commas separating items, and might allow newlines in strings, or might not, etc.). XML is easily transformed and manipulated by software. XML is structured to allow arbitrary data to be stored.
The alternative is a mass of undocumented text or binary data files which are meaningless without external documentation or software to interpret them.
This is the real question which is oft ignored. There is far too great an emphasis of being able to manage n CPUs rather than how effectively kernel services operate on n CPUs.
Absolutely. This is why we should be wary of claims that have been made (and posted on Slashdot recently) that Linux 'scales to 512 or 1024 processors' (as in some SGI machines). This size of machine is only effective for very specialised software. A report that the kernel scales well to 64 processors is far more believable, and is a sign of the increasing quality of Linux.
The grandparent poster said that Linux had supported systems for longer and cheaper than Windows.
No it didn't. Read it again. It said
Linux distributions generally provide much longer (and cheaper) support for older versions of the OS.
It said 'provide', not 'had provided'. You got the tense wrong. It's an on-going thing. For example, Debian provide resources for a smooth (free) updating of any earlier version to any required current version. There is no plan to stop this. Even if this did not go back to versions from a long time ago (it does) this would still be longer support than for Windows, as Microsoft products have limited support periods.
Fedora hasn't been around since NT4. The grandparent poster said that Linux had supported systems for longer and cheaper than Windows. My question was what Linux?
Both Debian (1995) and Slackware (1993-1994) distributions have been around, and have provided free upgrades, since before NT4 (1996).
But of course, this is irrelevant. The point is that distributions like these have no support time limits. They plan to provide free support and upgrades indefinitely. This is obviously not the case with Windows - there will always come a point at which a full upgrade to a new OS is required.
I don't know of a single commercial Linux distribution that has been maintained and patched for the same lifecycle as NT4
Why use commercial Linux? There are free upgrades for the kernel and most packages for systems like Fedora.
About number 2, nobody is forcing companies to buy new hardware or go with the latest OS. Many companies have stuck with NT4, or even 2000.
If they stick with these systems they lose support, which includes patches for major security issues. Linux distributions generally provide much longer (and cheaper) support for older versions of the OS.
By the way... thanks for a stimulating discussion!
You start with our own Universe
I disagree. Many models of universes start with assumptions which may, or may not, have anything to do with our universe (holographic models, string theory etc.). We don't know. They are just models. As we don't even know what our universe is, how can our models be based on it?
"Random" is not an explanation. It is merely a statement that an explanation is not possible given the information available. That is, you've figured out the how, but you can't figure out the why.
I would say that it is a statement that there is no necessity to figure out the 'why'. I would say that it means there IS no why! Anyone looking for a 'why' is wasting their time.
It's a postulate, and that's the point. Both the postulate "God created the Universe" and "The Universe evolved randomly to where it is" lead to the exact same Universe we have to day - either by God's choice, or the weak anthropic principle.
Yes, so why even bother with the more complicated (God) postulate? It serves no purpose. If you say 'God created the Universe', you might as well say 'two Gods created the Universe' etc, and so on. Best stick with the simplest option.
You're not adding any factors into any hypothesis you make regarding how the person acts.
That's not what I was saying. What I meant was that adding 'will' added complexity to the whole situation, not just why something happens.
(Personally, I believe that there are good philosophical reasons to believe that will DOES change how a person acts).
Let's face it - a cold turkey jump to OSS is damn difficult for any company.
Is it? I have done this several times. It really is no more trouble for end users than a switch from, say, win98 to XP. With good sysadmins, it can be a very smooth transition.
When you're creating relations between tables, a graphical table editor and a GUI that lays everything out for you is pretty nice and takes away alot of the eliteness of the DB world. I can get a moderately experienced office worker setup with Access very quickly, but using MySQL requires more experience.
If you install the JDBC driver, current versions (1.1.x) of Open Office does all this very nicely, and includes the ability to design forms and run mail merges.
Why would they do that ? MS Windows is free (as in "the PC isn't sold cheaper without it"), and can run Evolution, Firefox, OpenOffice.org, and basically every other program which would make Linux a better choice. Where is the incentive ?
1. Virus resistance. This can be a major advantage and time-saver in a large organisation.
2. No forced software and hardware update cycles.
3. Very easy remote support. Secure remote X11 access is either the default on Linux, or at least is simple to set up.
4. Versatility. Linux workstations are fully licensed to act as servers if the need arises.
5. Security. Linux workstations are by default set up with separate administrator accounts, and so the ability of users to mess about with their own machines (such as installing pirate software) is limited.
6. Often the PC IS sold cheaper without it! I can buy PCs installed with whatever Lindows is called now, and there is a significant saving.
Nah, that's just ways to discover more about our own current Universe, because the modeling is based upon the rules of our own Universe. It's a self-consistency check. In other words, we're making mathematical models of modified versions of our own Universe. Not new Universes altogether.
I have to disagree. Some of these models have nothing whatsoever to do with our universe (such as those with additional time dimensions).
I'm not talking about an intelligence, I'm talking about a will. Wills aren't complex or simple. They just are. This isn't an Occam's Razor issue in the tiniest bit.
It is, as having a will is more complex than not having a will - it's adding another factor.
The point that I'm making is that clues regarding a creator must be explainable via other methods. In other words, you can say "they're not clues", and I can say "they are clues", and we'd both be right.
No, as calling these 'clues' is to make a whole load of assumptions. It's not up to me to prove that they are not clues - it's up to you to prove they are. Having no assumptions is simpler.
Both viewpoints are equally, unprovably, correct. "Random" implies a point of view.
They are unprovable, but one is more sensible. If something can be explained by randomness, there is no need for another explanation. To add further explanation is to complicate things and requires a lot of work to prove.