The entire section on nodes and hashes has many factual errors and it key point is strongly misleading. The main point of this section is that Hash's are not order preserving thus the assumption that the language data model YAML implicitly encodes lacks the notion of order preservation. It points out that Perl and python lack order preservation.
Both are factually wrong. First the YAML spec clearly defines both order preserving and non-order preserving hash types. It's not an after thought, it's part of the main language. Second there is no implied native language data structure for YAML. third, YAML's array structure can be substituted as well to explicitly maintain order. {head : 1, foot : 2}
versus
[ head: 1, foot: 2 ]
Indeed the latter is exactly how some YAML parsers for languages lacking Hash types hold hashes nodes. (and in fact this is pointed out in the "pitfalls" section of the wiki page on YAML).
Moreover, Perl and python both have order preserving hashes as standard modules. So not only is the assertion they lack them wrong but it is not even really germane since it was cited to bolster the the point being asserted that XML does not mandate the use of a non-order preserving hash while YAML does (not true). When a document is read in to most YAML parsers there is no mandated data container. The standared parsers in Python and Perl both are event driven parsers that provide hooks to the user. They only default to those structures if the user does not define listseners for the node events from the parser. The fact that perl and python happen to have native non-order preserving hashes says nothing to that point: Just as XML may want to go into an order or non-order preserving container, so it is true for YAML. The difference is that YAML is structured so that the simple thing, using native hashes, is simple, while not so for XML due to the need to store tage names and attirbutes in addition to content.
Additionally Syck, the most popular YAML parser/emitter, provides options to set the default for hashes to order preservation, so this is almost universally available to users even when using languages with non-order preserving native hashes. Cems2 18:15, 31 October 2007 (UTC)
- Quick tip 1: Please feel free to add any clarifications to any article whenever you have them, but please refrain from sweeping deletions of entire subsections of the article. If you have specific problems with specific parts of the text, please indicate them by citing the text directly, not by re-phrasing with your own interpretation of the text. For example, above you specify:
the assertion (Perl and Python) lack (order-preserving hashes) (is) wrong ...
- Please re-read the article content you deleted. Please indicate where it makes any such assertion; that "Perl and Python lack order-preserving hashes" ... as far as I can see, it doesn't. Not now, nor did it before you deleted it.
- Moreover, you specified:
it was cited to bolster the the point being asserted that XML does
not mandate the use of a non-order preserving hash while YAML does
(not true).
- Again, no such "mandate" or "point" was ever indicated in the text that was obliterated from the article. The text says: certain trade-offs that may have to be taken into consideration ... a point you openly acknowledge when you state: "They only default to those structures if the user does not define listseners [sic] for the node events from the parser."
- If the user doesn't take the issue of non-order-preserving hashes into consideration, why and how would they ever consider fiddling with the defaults in the first place? If the option to change the defaults is available, then the issue must be relevant. If the issue is relevant, then people learn more by clarifying the issue, not by deleting it from the article wholesale.
- Quick tip 2: Please sign your discussion page posts and put them at the bottom of the discussion page. Thank you. dr.ef.tymac 02:20, 31 October 2007 (UTC)
Viewpoints and breakdown by cems2
- First I'll repeat that you are proceeding from a flawed analogy. Let me break this down by showing you the proper analogy. In your analogy you are comparing an ordered array in XML to a YAML hash. I realize you don't understand what I'm saying yet so please forgive my pedantic breakdown of the proper XML YAML analogs. But I think this will clear up the error.
Similarly, arrays present a trade-off because arrays preserve declaration order, but are usually addressable only by a numeric index.
- This last senstence embodies some to the root of the confusion here. Namely the equivalent syntax you try to strike between XML and YAML are not choosen right. Here's some better equivalences
<XML>
<foo> manchu </foo>
<bar> car </car>
<foo> to make this obvious I repeat the foo tag </foo>
<\XML>
%YAML
- name: foo
content: manchu
- name: bar
content: car
- name: foo
content: See this is where your analogy goes wrong. because you could not have two foo taks if you were storing this in a hash.- So now you can see that you were writing an ARRAY in XML and trying to compare it to a HASH in YAML. You needed to compare it to an array like I showed. Now lets construct the HASH comparison
<XML>
<foo font = "helvetica", size = 7> </foo>
%YAML
name: foo
attributes:
font: helvetica
size: 7
- here we see that it's the attribute portion of XML, not the tag name portion, that is a proper key-value pair or hash. And we have the same representation of the attributes in YAML as a hash. The premise of the whole section is hung on striking the wrong analogy. The only point you might make on that score is that it is apparently easy for someone to mistunderstand what parts of XML are used for ARRAY forms and which part are apropos for HASH forms. But that belongs on the XML page.
- Look what you are saying here is simply mistaken and your own point of view on YAML, Both of those are reasons it does not belong in a wiki, Additionally the purpose of a wiki is not to teach nuances of implementation, though perhaps some tips are helpful. In this case however it seems to be trying too hard to make a point that can be dispensed with. Lets look at the meat to the section:
Because the two source fragments look substantially similar, one might be tempted to assume that they are processed similarly when loaded into a target programming language. This is not necessarily the case, however, as the YAML instance is capable of translating key-value pairs directly to a hash,[1] whereas the XML instance does not expressly specify any addressing or storage scheme whatsoever.
- That's a fictional distinction. XML and YAML use different terms to describe what they represent. In the XML world one here's people talk about Key-value pairs, named attributes. In YAML the term Hash is used. This does not mean that YAML targets a perl hash and XML does not. IN JSON they call them collections. Does this mean it's not a HASH? No they all are expressing a key-value relationship. But they don't specify the languages container.
This difference presents certain trade-offs that may have to be taken into consideration. For example, programming languages such as Perl and Python do not preserve the order of hash key-value pairs as they are originally specified in source code (at least not by default).[6]
- Perl and Python have order preserving "hashes" that are standard modules available in all distributions of the languange. There's not particular reason one has to instantiate a simple hash to be a YAML entity container.
This includes those that are defined and loaded from YAML. Instead, nodes declared as hash keys may appear in any arbitrary order when processed and loaded in to the program.
- if one specifies order preservation YAML preserves the order. If is not specified the user has control over how the YAML entities are stored in most yaml parsers. e.g. event driven parsers play the events in the as-written order of the tokens in the YAML file. If the user chooses to store the data out of order that's his problem. But the events come in the same order. The same is true of most XML parsers. The events happen int he order offered. But if the user is storing the XML events in a simple non-order preserving hash then they may get out of order. How for example would you store the named attributes in an XML tag? Every parser I know uses a HASH.
- thus given that the entire section seems to be very misleading and I recommended it's deletion. Cems2 18:15, 31 October 2007 (UTC)
Response
First off, the examples and analogies you specify here seem to indicate a particular reading of the article based on your own private assumptions. Your assumptions are fine for you, but they are not the only valid reading of the material. For example you stated:
you were writing an ARRAY in XML and trying to compare it to a HASH in YAML
You're free to look at it that way, but that's not the only way, especially since there is no concept of "array" (or "hash") in XML in the first place. Either it's well-formed or it isn't. That's precisely the point, parsing, node addressing and node storage are handled differently, not just between YAML and XML, but also between the different programming languages and parsers.
You looked at the XML and perhaps thought "he's trying to do an array" ... others look at the XML (and the YAML) and think "this is just text with a 'head' 'body' and 'foot' specified in that order. Many people (justifiably) assume that the text is just text and that the order they write it in will not be messed around with. This is especially true for people who are more familiar with XML than with YAML (i.e., most people on the face of the Earth).
This section explains some reason why such justifiable assumptions do not necessarily hold. This helps people who are just learning about YAML, XML, or even programming in general; people who are not experts and members of the "general audience" that Wikipedia is targeted to in the first place.
You seem to be assuming that there is always a "correct" way to represent and interpret data structures, and therefore deem the issue of non-order-preserving hash keys (among other issues) irrelevant, because anyone who knows enough will know how to handle it. (Indeed, anyone who uses YAML regularly will not be the slightest bit confused between a "sequence" type and a "mapping" type). That's fine, but the problem is there's a difference between knowing the solution for an issue and acknowledging the issue exists in the first place.
Not all readers of this article are going to be familiar with the issues. Before you can tell them the "correct" resolution of an issue, you first have to explain what the issue is to begin with. That's what makes Encyclopedia articles informative. That's how people learn.
Bottom line: There are plenty of YAML parsers that preserve hash key order as serialized in the raw text. There are plenty that do not (at least not by default). There are plenty that do, but only if configured to do so by the user. There are also other options such as using YAML::Omap. All that is just icing on the cake. The cake itself consists of telling people why any of this matters in the first place.
Just because there are workarounds for an issue doesn't mean we ignore the issue entirely.
If you can come up with better wording that makes this point even more clear to more (general audience) readers, have at it. Detailing what is "correct" or what "most YAML parsers" can do is putting the cart before the horse. Deleting the entire section is putting one person's interpretation above everyone else's. dr.ef.tymac 17:32, 31 October 2007 (UTC)
reply
- the wiki section needs to be removed because it simply is your interpretation, it's clearly contestable as I have shown, and it's misleading or poorly worded. Now to try to make this constructive, it would help if you could offer single sentence or two sentence statement of what the section is teaching the reader. For example, a statement like "YAML contains syntaxes that have no expression in JSON, including relational structures, and extensible type declarations." could preface a discussion of those. Or a statement like "XML has the notion of Valid in additon to well-formed, yaml only has the latter". Then one could go on to explain this. As it stands it raises a dubious strawman, and then...well it's not really clear what's being said. it seems to rely on language specific implematation idiosyncacies that have nothing to do with the YAML spec. On top of that the strawman is highly misleading as it is predicated on visual similarities not actual equivalent data content. So let's start there. What's being taught here? and is this an implementation idiosyncrasy, a pitfall, what?
- If the goal was to expose the object model differences between YAML and XML then I might be temped to say something like this instead (please forgive any too-sweeping generalizations and colloquial syntax) .
YAML and XML have different object models. YAML's object model maps more closely to the entities found in higher level languages such as Hash's, arrays, and pointers. To perceive this distinction consider the following. When representing XML in a higher level language one needs only two rules:
- 1. An XML object has exactly three attributes:
- name: <string>
- attributes: <hash of key values, where the values are scalars.>
- content_array: <array>
- 2. An XML object may only be contained by the content array of another XML object. The content array elements contains either a string or another XML object.
There! that's all one needs to represent any XML in a higher level language.
- Now there's multiple ways one could implement YAML objects. But the most primitive and most analogous is , I beleive the following.
- 1. A YAML object (called a node) has exactly two attributes
- type: <one of a set of defined keywords for types>
- content: < an object of the type defined above>
- 2. A YAML object can only be placed in the content of the array/hash value fields of another YAML object.
- Types here would most commonly be array,hash, pointers, or scalars (strings, ints, etc), though they could be any definable YAML type like ordered Hash, Binary, timestamp, set, or user defined class.
As can be seen a YAML object unbundles the fields of a higher order XML object such that it would take three YAML objects to represent the three fields of an XML object. Moreover there is no notion of a general hash hierarchy in XML (the attribute hash storage may only contain scalers not other objects), thus a hash notion can only be exist by user defined semantics imposed on the XML content and has no direct syntactic representation."
- That's one thought. it never raises the red herring of how one might visually confuse an order preserving array of XML objects (and as described, all XML objects are held in arrays) with an non-order preserving Hash of YAML objects. But that's just a visual issue, not a real one to anyone who understands that the containers are layed out differently: XML content is logically speaking always an array, and YAML is a flatter representation from which one can build the XML arrays. It's not a workaround. The two look-alike syntaxes are constructively different.
- If put this way we can dispense with the side topic of perl or python native hashes, which definitely don't belong here. The bold section seems to capture the issue you were describing.
- So if possible tell me what the issue you are trying to teach is. is it an idiosyncracy or pitfall? is it a structural comparison like I laid out? Then we can argue better. My own feeling is that the structural comparison I just outlined would not belong either even if it were better written. It's just not a WIKI kind of thing as the decomposition while instructive is also arbitrary. Cems2 18:08, 31 October 2007 (UTC)
proposed resolution
I think that the real underlying issue here may have a simple resolution. Basically, XML may have no syntax for a general hash construct. Hashes arise from semantic idioms imposed by the user. YAML has a direct syntax.
So perhaps we do the following: in XML comparison section we say something like, " YAML has direct syntax for HASHes whose keys can contain hierarchical content. XML has no direct syntax but a user can of course store a HASH in XML by imposing an external semantic structure (there are many possible idioms). " Additionally we add a paragraph to the pitfalls section pointing out that XML users who are accutomed to hash idioms that are order preserving may find YAMLs direct (and higher level language inspired) hash representation has the pit fall that it is not order preserving. When Order preservation is required one can either use YAML's defined order preserving hash type, or, in analogy to XML, an ordered array of key-value pairs."
Does that capture the two points you want to make here? Cems2 19:28, 31 October 2007 (UTC)
Alternate proposed resolution
Respectfully Cems2, your review of the issues here seems **way** more complicated than necessary. It's almost like you're writing your own specification here on the talk page. Your explanations are long, unsuitable for a general audience and appear to rely heavily on your own personal interpreations.
I'm going to try to make this as plain as possible, and break this into *extremely* simple points.
Point1: The logical structure of XML has the following primary items of interest:
- 1) Element
- 2) Attribute
- 3) the Element content-model (but only for XML documents with user-defined validity constraints)
Point2: The logical structure of YAML has the following primary items of interest:
- 1) Scalar
- 2) Sequence
- 3) Mapping
(All of these are built-in to the YAML specification and have nothing to do with user-defined constraints or target programming language or differences in parsers)
Point3: According to the YAML specification, in the YAML representation model, mapping keys do not have an order ... in every case where node order is significant, a sequence must be used. .
Point4: In the XML specification, in the Element content model, there is no logical structure equivalent to a YAML mapping, and there is no requirement in the specification that a user choose a logical element of XML depending on whether she wishes to represent order-preserving versus non-order-preserving node relationships.[1] Even for validation under the element content model, there are only three possible constructs: 1) choice; 2) sequence; or 3) mixed -- there is no construct equivalent to YAML's 'non-order-preserving mapping'.
Request: For starters on the road to resolution, please answer with a simple yes or no -- do you dispute any of the above four points? dr.ef.tymac 02:20, 1 November 2007 (UTC)
- I Agree that this is true. Small but relevant quibbles. Point 3 is general statement that includes mixed type nodes (so yes), but for pure hash nodes an ordered hash does preserve order. Point 1, and point 2 while individually correct (so yes) are not at the same level of resolution: an XML "node" if you will implicitly needs all 3 items to define it, but in YAML a node is one of the 3. I'm not perfectly certain I understand the jargon in point 4, but the but the first quoted phrase and the last hyphenated phrase which I assume is the point I accept (so yes)
- so then we seem to agree that XML has no Hash concept, and acts like an array in YAML would.User:cem2 02:42, 1 November 2007 (UTC)
- As far as the "jargon" in point four, it comes directly from the XML specification, indeed, all the points above depend directly on the relevant specs. I'm just focusing on the specifications now because those are documented for anyone to read, and not my own original research. So, if I am not mistaken, you do not dispute any of the above points.
- Request: Here's the next "yes or no" question. Does the YAML specification itself provide *any* built-in mechanism for indicating or representing a key-value-order-preserving mapping? (I'm not talking about language-specific libraries, or hashes, or parser implementations, I'm talking about mappings as defined in the YAML specification itself). dr.ef.tymac 02:59, 1 November 2007 (UTC)
- Answer: Yes. The YAML specification itself formally defines two URIs !!omap and !!pairs for ordered maps (there's also third kind too, !!seq, for key-value pairs in which the value field is null--effectively this is a ordered set which is a special usecase of a hash.) . (you can tell it's a "built-in" and not a library or local type because it's a double exclamation. ) User:cems2 04:47, 1 November 2007 (UTC)
- Request: Excellent. Do you agree that the YAML specification does not mandate support for !!omap? Is a YAML processor compliant with the YAML specification if it does not support !!omap? . dr.ef.tymac 11:20, 1 November 2007 (UTC)
- Answer: No. Ordered maps are in the spec. They are a URI, so they are defined for all YAML processors. I'm not sure whay were now talking about YAML processors, but I shall answer anyhow. The YAML spec says that a "YAML Processor" can parse any type even if it does not have a native representation for the type or even known what the tag is. So your questions are moot. However, in this case we can say even more: the tag definition for omap anticipates that not all languages have a ordered map, it therefore also instructs how to handle the OMAP in such a case. So this can be implement not only on any YAML processor, but also in any impmentation language. Thus OMAPs are URIs, processable by any YAML spec compliant processor or native language. Anyhow, this Q&A is not any sort of proposed resolution so far despite the section title. SInce it's not getting us anywhere I suggest we discuss the concrete resolution I proposed and you tell me what's missing. 67.40.194.160 23:08, 1 November 2007 (UTC)
Even for attributes, when more than one definition is provided for the same attribute of a given element type, the first declaration is binding and later declarations are ignored.
Please lets keep the discussion focused on simple answers and *reliable sources*
The problem with your proposed resolution is it doesn't seem to incorporate any direct references to reliable sources. It's also a bit turgid and very ambiguous in places. Also, you bring up implementation languages and other outside concepts instead of focusing solely on the [YAML representation model].
The alternate proposed resolution is to please stick to "yes or no" for now because that is the only thing that is helping to clear up these unhelpful ambiguities. Please also stick to direct citations from the specifications, and I will do the same.
Also, please make your "yes or no" answers clear and unambiguous so there's no room for "misinterpretation" (please don't answer a compound question with multiple conditions with just a single "yes" or "no"). If you really are interested in correcting my "flawed analogy" and "confusion" there's no better way to do it than with direct "yes or no" responses; therefore none of these questions is "moot".
- 1) Yes or no: Does the YAML specification mandate support for !!omap?
- 2) Yes or no: If "yes" to above, do you have a direct citation to the spec, or any authoritative source to support your answer?
- 3) Request: If "yes" to 2 above, please provide a direct citation to the relevant section of the spec here in talk.
Please, let's keep this discussion on track and focused on direct citations to the spec so we can move forward. The best "concrete resolution" to solve "what's missing" is to clarify all relevant issues with direct references to reliable sources. That's what Wikipedia is all about. dr.ef.tymac 23:46, 1 November 2007 (UTC)
- Answer. I don't know what you mean by "mandate". I cited the YAML spec, and the definition of !!omap. The defintiion of the YAML processor in the YAML spec means it can process any well-formed tag on a node and a I cited the recpie for implementation is given for languages without native hash given above. Please state your proposed reolution so I can see where this is leading.67.40.194.160 02:13, 2 November 2007 (UTC)
- Where is this going: My proposed resolution is: Step1) confirm and clarify that you and I both indeed understand the underlying issues; Step2) based on that confirmation, arrive at (2a) an agreed and (2b) an authoritative (i.e., directly cited) understanding; and Step3) based on that understanding, clarify or remove any part of the contested section that is not consistent with that mutually-agreed and authoritative foundation.
- Mandate: These "yes or no" questions are helping to illustrate critical problems. For example, the term "mandate" (or "mandatory") is a very precise and crucial technical term that applies to requirement levels in specifications. Its meaning and application can be found at IETF RFC 2119. Failure to understand this term and related concepts seriously diminishes the quality and credibility of this discussion, and by extension, the authoritativeness of this Encyclopedia article.
- Specification: As far as I can see, the only link you provided was to the yaml.org "types repository" -- but not to the specification itself, despite the fact that you've offered several definitions, formulations and conclusions that cannot be (authoritatively) resolved by citing the "types repository" alone.
- Comment: Without sufficient coverage of critical concepts, this discussion is not authoritative and lacks credibility. Without clear and unambiguous answers, resolution Step1 and Step2a cannot be completed. Without direct support from citations for all significant assertions made here in discussion, resolution Step1 and Step2b cannot be completed. Without completion of these steps, any "proposed resolution" is a waste of time because there is insufficient evidence to prove all participants are providing clear, consistent, non-contradictory, and verifiable explanations; or even that they know what they are talking about to begin with.
- Request: Please take a moment to review critical concepts and re-answer (if you wish), and please provide direct support from the YAML specification (or any other equally authoritative source), so readers of this discussion page and the WP article can verify the credibility of all assertions, and so we can make progress to resolve this matter efficiently and definitively. Thanks. dr.ef.tymac 11:35, 2 November 2007 (UTC)
How Wikipedia works
This one-way interrogative form of discource is not my cup of tea and it's overkill for the issue. Please state what it is you want to teach in this section of the Wiki. I objected to the current section, which does not exactly follow the standards you are hewing to in this discussion. To be constructive I've also have made several guesses as to what the objective is and how to accomplish it. But I must not have nailed it since it does not seem to satisfy you. So what is it that you are driving at. I can't help if you won't say. If you are taking umbrage that I deleted your section then let me apoligize: I waitied too littlte time after posting my original objections in the discussion section. —Preceding unsigned comment added by 67.40.194.160 (talk) 04:07, 3 November 2007 (UTC)
- It seems you may be mistaken on the fundamental purpose of Wikipedia itself. You said:
- Please state what it is you want to teach
- The purpose is not to teach anything. The purpose is to produce an Encyclopedia article that is based on content from reliable sources. If you want to contest or delete content please feel free to do so, you are entirely free to do so, I welcome you to do so, just make sure your objections are founded on reliable sources and not a "personal lesson plan". People should be able to learn from the article, but the article should not be derived from unsubstantiated claims and "guesses".
- I objected to the current section, which does not exactly follow the standards
- If that's how you feel, great! I am happy to work with you if it means improving the article. I am not happy, however, to read through long turgid explanations that don't even cite the YAML specification, since that's what this entire article is based on. I don't know of a better way to clear up ambiguity than to answer simple "yes or no" questions -- otherwise, your answers have been non-cited and full of apparently "original ideas". That's fine for you, but not for Wikipedia.
- To be constructive I've also have made several guesses as to what the objective is
- This is exactly the problem. "Personal guesses" are the opposite of constructive. If you have specific passages of text from the YAML specification itself that indicate there are errors, (or you have other equally authoritative sources), please present those ... please do not present guesses as they are long, turgid, unsuitable for a general audience, ambiguous, not cited by sufficient authority, and not likely to get this matter any closer to resolution.
- So what is it that you are driving at.
- How many times do I need to say it? If you have a correction to make to the article, hooray! That's a *good* thing. Just please make sure your "corrections" are based on the content from reliable and authoritative sources, and not just your own personal ideas.
- If you are not familiar with the material in authoritative and reliable sources, please read them first and then come back when you feel ready to discuss. For example, not understanding the requirement levels of IETF RFC 2119 is a huge barrier to any productive discussion, because it is a central part of "what I am driving at".
- Repeat: My goal is not to "teach" anything. My goal is already plainly stated in Where this is going above, in clearly defined steps. Is there any specific part of that you find objectionable or unreasonable? Please tell me. I am happy to work with you. I am happy to change anything you want to change as long as you can state your case clearly, authoritatively, and unambiguously -- and as long as it is consistent with Wikipedia policy. This is not a blog or a tutorial site. Long, non-cited "guesses" and "corrections" are not going to help improve this article. dr.ef.tymac 12:01, 3 November 2007 (UTC)
- since you are unable to explain your insertion in plain english, please delete it until you can. 67.40.194.160 06:05, 4 November 2007 (UTC)
- Yes or no ... in plain english: Does the YAML Specification mandate support for !!omap?
- You haven't answered my *very simple* question. I've even given you links to define the critical terms that you need to understand in order to answer.
- Since you are unable (or unwilling) to provide simple "yes or no" answers (I'm still waiting for a "yes or no" answer to "Mandate" by the way); and since you are unable to support your assertions with citations to the YAML specification; and since you have yet to demonstrate you have even read (let alone understand) the citations I've provided to you; please go read WP:OR, WP:V and make a good faith effort to prove to me that your failure to honor *any* of these simple requests is just an oversight on your part.
- I've done a lot of "plain English" explanations, and I've done everything short of spoon-feeding you the citations one word at a time. It's not my responsibility to teach you concepts that you have yet to demonstrate you understand in the first place. Please answer my *very simple* yes or no question (and support it with a cite, not just your own "guesses"). Then I can determine the level of explanation you will need. Thank you. dr.ef.tymac 12:29, 4 November 2007 (UTC)
Moving forward
I've begun to make already-planned enhancements to the section that was deleted, rendering most of the objections offered here irrelevant. Of course, if there are any future objections or concerns, they are more than welcome, but please: 1) substantiate all material assertions with direct references to cited sources so no one has to "guess" about anything; and 2) be prepared for simple "yes or no" questions if it becomes necessary to clarify any ambiguities.
Please do not post deletions or objections unless you can honor these two very simple requests. Thanks. dr.ef.tymac 16:17, 4 November 2007 (UTC)
This article is or was the subject of a Wiki Education Foundation-supported course assignment. Further details are available on the course page. Student editor(s): Vchitto, Dbzvishal.
