The Artima Developer Community
Sponsored Link

Weblogs Forum
Version Control is Undo

83 replies on 6 pages. Most recent reply: Jan 27, 2009 4:17 AM by Dhruva Krishnamurthy

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 83 replies on 6 pages [ « | 1 ... 2 3 4 5 6 | » ]
James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more Posted: Dec 10, 2008 9:07 AM
Reply to this message Reply
Advertisement
> Manipulate does not always mean 'modify'; it can mean
> 'process' or 'copy and modify'.

In the context of data 'manipulate' does in fact mean to modify. And if you don't need to change it, then what's the advantage that you are speaking of?

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Version Control is Undo . . . or more Posted: Dec 11, 2008 4:37 AM
Reply to this message Reply
> universal: including or covering all or a whole
> collectively or distributively without limit or
> exception

> http://www.merriam-webster.com/dictionary/universal

Data do not have meaning by themselves; someone else always extracts meaning from them. And then the same data can mean different things for different people.

Posting the definition of 'universal' does not help in the discussion.

When we say 'universal format', we mean something that all computers and programs can read and extract structural information about the data.

> You are affirming my point. XML cannot processed as
> source code without some definition of what the elements
> mean.

No. You confuse structure with meaning. The universal format should give structure to unstructured collection of bytes, it should not assign meaning to the structure. The meaning should be left open to interpretation.

> Tell me what this means (real world field names):
>

> <rctcdp>
> <dqp2nb>123456789</dqp2nb>
> <dqoinb>999</dqoinb>
> </rctcdp>
>

> The above is no more meaningful than this equivalent
> data:
>

> rctcdp {
> dqp2nb: 123456789
> dqoinb: 999
> }
>

> Or this:
>

> rctcdp
> dqp2nb = 123456789
> dqoinb = 999
>

>
> The only difference between these is that the first one
> can be parsed using easily obtained tools in many
> different languages.

The meaning is different for each person. The point here is that both you and I can read the data. The meaning we give to those data depends on many parameters.

> Great. When the tools are improved, let me know.

So do you mean that the tools can not be improved?

> I'm not advocating using word documents for code. As I've
> said before, the only worse format for code than XML is
> Word ;)

It was just an example. All kinds of information are needed to have a format.

> You are unable to see the forest for the trees.

Can you elaborate on that? one sentence arguments do not help the discussion.

> XML is a subset of free text.

No. Free text does not have structure.

> I know, BNF grammars do.

If you know, then how come you say that XML is a subset of free text? neither BNF or XML is a subset of free text.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Version Control is Undo . . . or more Posted: Dec 11, 2008 4:42 AM
Reply to this message Reply
> > The classic C++ ambiguity:
> >
> > With a structured format, no parsing ambiguity:
>
> Not all source is C++. In fact you have proven that text
> based formats can be unambiguous given that XML is text
> based.
>
> Why do you assume that the source must be C++?

Ok, forget c++. Here is a (hypothetical) email:

sender: john receiver receiver: jim sender jim, text is dead, we need a better format.


Here the sender is called 'john receiver'. The last name of this person causes a parsing ambiguity.

If the format was like this (XML used for example, it could be JSON or something else):


<sender>john receiver</sender>
<receiver>jim sender</receiver>
<text>jim, text is dead, we need a better format.</text>


Which has no ambiguities.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Version Control is Undo . . . or more Posted: Dec 11, 2008 4:44 AM
Reply to this message Reply
> > Manipulate does not always mean 'modify'; it can mean
> > 'process' or 'copy and modify'.
>
> In the context of data 'manipulate' does in fact mean to
> modify. And if you don't need to change it, then what's
> the advantage that you are speaking of?

The advantage is easiness to extract structure and then all sorts of meaning, depending on context.

Since you posted an online dictionary earlier, it's only fair that I post one as well about the world 'manipulate': http://www.merriam-webster.com/dictionary/manipulate

At best, it means 'manage', not 'modify'.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more Posted: Dec 11, 2008 6:51 AM
Reply to this message Reply
> > XML is a subset of free text.
>
> No. Free text does not have structure.

The structure exists only in interpretation. If I didn't know what XML is, it would be free text.

> > I know, BNF grammars do.
>
> If you know, then how come you say that XML is a subset of
> free text?

Because it is. Perhaps 'subtype' is more clear. The set of all cXML documents a subset of all XML documents. The set of all XML documents is a subset of all text documents. There is nothing in XML that cannot be represented in text. XML is text. 'Free' just means that it can contain things like XML and also things like JSON and also things like email. It's only XML if I choose to treat it as XML. If I want to treat XML as 'free-text' nothing is stopping me from doing so.

> neither BNF or XML is a subset of free text.

The BNf grammar (or any other grammar) provides the limitations that allow a text based format to be understood without ambiguities. If a grammar still allows for ambiguities, that's a problem with that particular grammar. Just as we can create ambiguous XML, it's up to the designer of the specification to eliminate the ambiguities. It's not something inherent about text. And in any event, arguing that XML is better than text is nonsensical. Do you really think I'm proposing that unstructured text be used to represent source code?

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Version Control is Undo . . . or more Posted: Dec 11, 2008 8:16 AM
Reply to this message Reply
> The structure exists only in interpretation. If I didn't
> know what XML is, it would be free text.

You can't handle what you don't know, that's a principle of the universe :-).

The Universal Data Format would be the minimal 'agreement' on how data should be structured.

> Because it is. Perhaps 'subtype' is more clear. The set
> of all cXML documents a subset of all XML documents. The
> set of all XML documents is a subset of all text
> documents. There is nothing in XML that cannot be
> represented in text. XML is text. 'Free' just means that
> it can contain things like XML and also things like JSON
> and also things like email. It's only XML if I choose to
> treat it as XML. If I want to treat XML as 'free-text'
> nothing is stopping me from doing so.

But that does not mean that conceptually XML is a subtype of free text.

Java source programs are not subtypes of free text.

C++ source programs are not subtypes of free text.

BNF is not a subtype of free text.

> The BNf grammar (or any other grammar) provides the
> limitations that allow a text based format to be
> understood without ambiguities. If a grammar still allows
> for ambiguities, that's a problem with that particular
> grammar. Just as we can create ambiguous XML, it's up to

XML can not be ambiguous.

> the designer of the specification to eliminate the
> ambiguities. It's not something inherent about text. And
> in any event, arguing that XML is better than text is
> nonsensical. Do you really think I'm proposing that
> unstructured text be used to represent source code?

No, but you propose that each text file to have its own parser, i.e. leave things as they are today.

What I am saying is that is data should have a common parser. At least structure shouldn't be a problem, only meaning.

In the "immortal" words of TinyXML author (http://www.grinninglizard.com/tinyxml/):

I found myself writing a text file parser every time I needed to save human readable data or serialize objects; I created TinyXML to solve the text I/O file once and for all.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more Posted: Dec 11, 2008 8:58 AM
Reply to this message Reply
> But that does not mean that conceptually XML is a subtype
> of free text.

I'm not sure I agree but what difference does it make anyway? What's your point?

> Java source programs are not subtypes of free text.
>
> C++ source programs are not subtypes of free text.

Of course they are. If the source is not text, what is it exactly. In what was is the ascii source of C++ and Java not text?

> BNF is not a subtype of free text.
>
> > The BNf grammar (or any other grammar) provides the
> > limitations that allow a text based format to be
> > understood without ambiguities. If a grammar still
> allows
> > for ambiguities, that's a problem with that particular
> > grammar. Just as we can create ambiguous XML, it's up
> to
>
> XML can not be ambiguous.

<entity>
<entity>John</entity>
<entity>Smith</entity>
</entity>

The above is XML and is ambiguous. XML doesn't solve anything aside from being easier* to parse. You still have to do the work to determine a good way to structure your data which is really important when your data is code.

*easier only because there are existing libraries. XML is actually really difficult to parse properly if you actually follow the full specification.

> > the designer of the specification to eliminate the
> > ambiguities. It's not something inherent about text.
> And
> > in any event, arguing that XML is better than text is
> > nonsensical. Do you really think I'm proposing that
> > unstructured text be used to represent source code?
>
> No, but you propose that each text file to have its own
> parser, i.e. leave things as they are today.

Then why keep making making the suggestion that anything but XML will result in ambiguities? It's a waste of my time and yours.

> What I am saying is that is data should have a common
> parser. At least structure shouldn't be a problem, only
> meaning.

And I think this is the wrong solution. A better solution would be to improve parsing tools. Your solution is like telling someone to get glasses because their computer monitor is out of focus.

In my opinion, the overuse of XML is a result of laziness. It's a technically inferior solution to any number of alternatives. And to be fair to XML, it was never designed for a lot of the purposes it's used for today. It's a pretty decent markup language for documents but for code and data, it's dreadful.

I have used a number of tools that represent code as XML and the XML was a huge pain in the ass. Our source control (which was theoretically XML-aware) couldn't make sense changes so we had to do manual merges. All the encoding made it impossible to read. XML doesn't provide any mechanism for breaking up a document across files so all that logic has to be hand coded, first by the vendor and again be the users of the tool if they want to do any custom analysis.

> In the "immortal" words of TinyXML author
> (http://www.grinninglizard.com/tinyxml/):
>
> I found myself writing a text file parser every time I
> needed to save human readable data or serialize objects; I
> created TinyXML to solve the text I/O file once and for
> all.


And other people regret using XML for programming languages, such as the creator of Ant.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Version Control is Undo . . . or more Posted: Dec 11, 2008 3:07 PM
Reply to this message Reply
> No. BNF is not more structured than XML. Actually, they
> can't be compared. BNF is the schema, XML is a storage
> medium.
Actually, XML specifies both a schema (XML Infoset, http://www.w3.org/TR/xml-infoset) and a storage format (http://www.w3.org/TR/xml).
Instances of the XML Infoset can stored in an XML-enabled database, or as a binary files, besides XML.

An IDE could display it even diffently if it was used as a base schema for a programming language. This could also erase the pesky &lt; occurences in XML files that contain logic (when shown in an intelligent editor/differ).

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Version Control is Undo . . . or more Posted: Dec 12, 2008 6:14 AM
Reply to this message Reply
> I'm not sure I agree but what difference does it make
> anyway? What's your point?

It seems the point of this discussion is lost. Let me state it again: it would be much better if there was a structured format for all data instead of plain raw bytes.

In this light, a structured format for source code would be better than plain text.

> Of course they are. If the source is not text, what is it
> exactly. In what was is the ascii source of C++ and Java
> not text?

Source code is not text, it is source code. It contains more properties than a simple text file.

> > XML can not be ambiguous.
>

> <entity>
> <entity>John</entity>
> <entity>Smith</entity>
> </entity>
>

> The above is XML and is ambiguous. XML doesn't solve
> anything aside from being easier* to parse. You still
> have to do the work to determine a good way to structure
> your data which is really important when your data is
> code.

It's not ambiguous at all. You have an entity consisting of two other entities.

> *easier only because there are existing libraries. XML is
> actually really difficult to parse properly if you
> actually follow the full specification.

Ok, but I never said XML should be the universal data format. I said it's a step on the right track.

> Then why keep making making the suggestion that anything
> but XML will result in ambiguities? It's a waste of my
> time and yours.

What we (as programmers and users) want is a structured data format to make our lives easier.

> And I think this is the wrong solution. A better solution
> would be to improve parsing tools. Your solution is like
> telling someone to get glasses because their computer
> monitor is out of focus.

But parsing tools can not be improved any more. The C++ grammar is not context free, it's like hell trying to parse C++. You have to have a full compiler in order to parse it.

The problem of parsing can totally be a thing of the past if a structured data format is used. If a structured format was used, there would be no need for parsing C++, Java, C#, Word documents, html, you name it!

> In my opinion, the overuse of XML is a result of laziness.
> It's a technically inferior solution to any number of
> f alternatives. And to be fair to XML, it was never
> designed for a lot of the purposes it's used for today.
> It's a pretty decent markup language for documents but
> t for code and data, it's dreadful.

It has its problems, but it also has many benefits. The best thing that happened with XML is that it opened people's eyes about structured formats.

>
> I have used a number of tools that represent code as XML
> and the XML was a huge pain in the ass. Our source
> control (which was theoretically XML-aware) couldn't make
> sense changes so we had to do manual merges. All the
> encoding made it impossible to read. XML doesn't provide
> any mechanism for breaking up a document across files so
> all that logic has to be hand coded, first by the vendor
> and again be the users of the tool if they want to do any
> custom analysis.

So the tools could be improved, eh? ;-)

>
> And other people regret using XML for programming
> languages, such as the creator of Ant.

I don't see how Ant had a problem with XML.

I am using XML a lot in my projects, and it has worked fine so far. I have used XML in the following domains:

1) a generic tool for simulating communication protocols (used internally in our company to qualify our products). It's great: you define the protocols with the IDE, which produces a series of XML files. Then other tools, language-specific, are used to convert the XML to message implementations for C++ and Java.

2) as a file format for persistent data for the products mentioned above. XML is very good for persistence, not only because it allows saving/loading files, but it also allows us to copy/paste data through the clipboard.

3) in my personal projects, as a format for my game tools: the tilemap editor saves files in XML, the game engine loads those files.


3)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more Posted: Dec 12, 2008 6:40 AM
Reply to this message Reply
> > I'm not sure I agree but what difference does it make
> > anyway? What's your point?
>
> It seems the point of this discussion is lost. Let me
> state it again: it would be much better if there was a
> structured format for all data instead of plain raw
> bytes.

I never argued for anything different.

> In this light, a structured format for source code would
> be better than plain text.
>
> > Of course they are. If the source is not text, what is
> it
> > exactly. In what was is the ascii source of C++ and
> Java
> > not text?
>
> Source code is not text, it is source code. It contains
> more properties than a simple text file.
>
> > > XML can not be ambiguous.
> >

> > <entity>
> > <entity>John</entity>
> > <entity>Smith</entity>
> > </entity>
> >

> > The above is XML and is ambiguous. XML doesn't solve
> > anything aside from being easier* to parse. You still
> > have to do the work to determine a good way to
> structure
> > your data which is really important when your data is
> > code.
>
> It's not ambiguous at all. You have an entity consisting
> of two other entities.

But the meaning is ambiguous. It's really a first and last name of a person. It's not fundamentally different than your C++ ambiguity example.

> > *easier only because there are existing libraries. XML
> is
> > actually really difficult to parse properly if you
> > actually follow the full specification.
>
> Ok, but I never said XML should be the universal data
> format. I said it's a step on the right track.
>
> > Then why keep making making the suggestion that
> anything
> > but XML will result in ambiguities? It's a waste of my
> > time and yours.
>
> What we (as programmers and users) want is a structured
> data format to make our lives easier.

XML doesn't make my life easier. It's a problem I deal with.

What is your definition of a structured format. Java code is a structured format, in my view. Do you agree?

> > And I think this is the wrong solution. A better
> solution
> > would be to improve parsing tools. Your solution is
> like
> > telling someone to get glasses because their computer
> > monitor is out of focus.
>
> But parsing tools can not be improved any more.

Hah! Only XML related tools can be improved, right?

> I don't see how Ant had a problem with XML.

I didn't say anything about you. I said the creator regrets using XML instead of writing a parser:

"James Duncan Davidson, the original creator of Ant, who later came to admit that

1. He originally chose to use XML as the format for Ant scripts because he didn't want to write a parser, and
2. He really regrets it and apologizes to the Java community at large for it."

http://blogs.tedneward.com/2005/08/22/When+Do+You+Use+XML+Again.aspx

> I am using XML a lot in my projects, and it has worked
> fine so far.

I use XML all the time. It's unavoidable. That doesn't mean it's a good choice for a programming language. I want something that can be read and modified without using tools and XML doesn't fit those requirements.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more Posted: Dec 12, 2008 11:48 AM
Reply to this message Reply
> It has its problems, but it also has many benefits. The
> best thing that happened with XML is that it opened
> people's eyes about structured formats.

I will give you that it's definitely shown that a consistent hierarchical base for a programming language makes it much easier to parse into a tree. Of course, this was already being done in LISP ages ago.

The problems are that it's way to verbose, uses <, > and & as special restricted symbols, and is far too complicated than it needs to be. For example on the last point, mixed-content elements are not something you see commonly in data or code oriented XML but you have to account for them. And there's also the redundancy of attributes. They don't really add any value in terms of what you can represent. Then there's the entities which almost no one uses for data or code and namespaces which can be useful but cause more pain than they are worth.

Once you trim all that down, you have a tree and a verbose way to represent it as text. It's really not that hard to design a text format that maps reliably to a tree. It's the interpretation of the tree that's the trick and XML doesn't help with that at all.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Version Control is Undo . . . or more Posted: Dec 18, 2008 6:43 AM
Reply to this message Reply
> I never argued for anything different.

Ok, I just replied to your question 'what is the point etc'.

> But the meaning is ambiguous. It's really a first and
> last name of a person. It's not fundamentally different
> than your C++ ambiguity example.

Parsing != meaning. A parser recognizes structures, it's not about meaning.

The problem that exists in the world of computers is that different applications can't parse the same documents, unless they share the parser code.

The common data format would solve the parsing problem.

> XML doesn't make my life easier. It's a problem I deal
> with.

You failed to show why though.

>
> What is your definition of a structured format. Java code
> is a structured format, in my view. Do you agree?

It is, but it is not universal. It's for Java.

> Hah! Only XML related tools can be improved, right?

No, all tools can be improved. But there is an obstacle...it's called 'non-context free grammars'.

For example, c++ has a non-context free grammar, and therefore, in order to parse it, one needs a full blown compiler.

Java does not have this problem.

But, if there was a common structure format, the parsing problem would be solved (with one tool, instead of many).

> I didn't say anything about you. I said the creator
> regrets using XML instead of writing a parser:
>
> "James Duncan Davidson, the original creator of Ant, who
> later came to admit that
>
> 1. He originally chose to use XML as the format for Ant
> Ant scripts because he didn't want to write a parser, and
> 2. He really regrets it and apologizes to the Java
> ava community at large for it."
>
> http://blogs.tedneward.com/2005/08/22/When+Do+You+Use+XML+A
> gain.aspx

The arguments presented in the blog are all ...stupid. Let's examine them:

1) "XML is a hideously verbose format"

a) So? it's not that Ant scripts would be thousands of pages long.

b) it can be compressed very well.

2) "in using XML is that it is a strictly-hierarchical format, and not everything follows a strictly hierarchical format"

a) It's a well known problem of XML. But that does not diminish XML's usability.

b) it can be solved by using references to other nodes via attributes. I've done it in 20 lines of C++ code, I don't see how Ant developers missed that. What I've done is to assign an 'id' to each node I wanted to link to, then reuse the id. As I read the DOM model, I had a map of ids to objects, and whenever I found a reference to an id, I used the map to get the object.

3) "and the "self-descriptive" tags that everybody blathers on about are only self-descriptive to carbon-based life forms (and then only if semantically-rich terms are used for the tag names). For example, does this "self-descriptive" XML have any meaning to you? "

a) I call bullshit. Instead of naming your tags 'p', 'ph' and 'a', use descriptive names.

b) It's the same as if I had Java methods with name 'p', 'ph' and 'a'.

> I use XML all the time. It's unavoidable. That doesn't
> mean it's a good choice for a programming language. I
> want something that can be read and modified without using
> tools and XML doesn't fit those requirements.

Bogus argument my dear Watson. You still use tools to manipulate your text files: text editors.

You also failed to show why XML tools are worse than text-editing tools. They are both tools.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Version Control is Undo . . . or more Posted: Dec 18, 2008 6:51 AM
Reply to this message Reply
> The problems are that it's way to verbose

It's not a problem.

Use compression if your data are too big.

> , uses <, > and &
> as special restricted symbols,

Some characters are required as language symbols; no problem with that. Keyboards have limited keys, and the symbols we use in math are chosen from a limited set.

Still, no problem at all.

and is far too complicated
> than it needs to be. For example on the last point,
> mixed-content elements are not something you see commonly
> in data or code oriented XML but you have to account for
> them.

What do you mean 'mixed-content'?

> And there's also the redundancy of attributes.
> They don't really add any value in terms of what you can
> n represent.

No, they do; they minimize verbosity. Example:


<foo attr1="a" attr2="b"/>


instead of:


<foo>
<attr1>
"a"
</attr1>
<attr2>
"b"
</attr2>
</foo>


> and namespaces which can be
> useful but cause more pain than they are worth.

I never used namespaces, and I never had a problem. Why should anyone use them? if you have two identifiers with the same meaning, just prefix them with something and then problem solved.

> Once you trim all that down, you have a tree and a verbose
> way to represent it as text. It's really not that hard to
> design a text format that maps reliably to a tree. It's
> the interpretation of the tree that's the trick and XML
> doesn't help with that at all.

I never said XML is the best thing since slice bread. I said (quote for the 3rd time):

"One step in the right direction is XML"

It's a step in the right direction, not a panacea.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Version Control is Undo . . . or more Posted: Dec 18, 2008 7:39 PM
Reply to this message Reply
> What do you mean 'mixed-content'?

I'm kind of bored with this discussion and there's no way you will convince me that XML is a good format for code. I have too much experience with XML. Likewise, you seem set in your belief that it is an improvement over the more classic structured language approach.

But I will answer the above. Mixed-content elements are those that contain both text and elements. They are useful in markup for documents e.g.:
<para>The quick brown fox jumped over the <emphasis>lazy</emphasis> brown dog</para>

This is why when you use something like DOM or SAX you need to account for multiple text nodes in an element. For some reason some parsers return multiple nodes even when there is no mixed-content.

This feature is great for marking-up documents (what XML was designed for) but not useful otherwise. That's the issue with XML. It's not designed for code/data and has lots of features that aren't needed for that purpose and has others that are problematic for that purpose.

Wolfgang Lipp

Posts: 17
Nickname: wolf2005
Registered: Sep, 2005

Re: Version Control is Undo Posted: Dec 29, 2008 6:09 AM
Reply to this message Reply
maybe the truth lies in the middle, or, ehr, in the double: you would have, for each file (of importance) a versioning control where you commit and comment yourself, and a second one in the background that does unattended and probably uncommented commits. that way, the wealth of fine-grained changes will not bog down your project, and you can still go back and forward between saved versions even if the editing software didn’t allow you to do that.

the main advantages of a time-machine like system i can see are (1) most up-to-date applications with multiple undo forget undo state when a document is closed and re-opened; (2) when you go back in such an application and then do change the document, the forward history is forgotten. in a text editor, you often want to go back and grab some piece you inadvertently had dumped, then walk back to the present state and insert it there, but it’s all too easy to hit the wrong key and bang! go all your precious changes. with a real vcs, you can have branching histories; (3) using version history as a system service, application design can become simpler; it boils down to presenting a well known api. application designers can even choose not to care for undo functionality at all, as the system itself will provide an undo facility that is potentially more powerful than what most applications offer today.

Flat View: This topic has 83 replies on 6 pages [ « | 2  3  4  5  6 | » ]
Topic: Report on an Unconference in Poland Previous Topic   Next Topic Topic: The Demise of the Headhunter

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use