<p>Controllers are classes. Methods should be defined on MyCtrl.prototype.
- See <ahref="http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showone=Method_and_property_definitions#Method_and_property_definitions">
+ See <ahref="https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showone=Method_and_property_definitions#Method_and_property_definitions">
the JavaScript style guide</a></p>
<p>Google Angular applications should use the <b>'controller as'</b> style to export the controller
@@ -343,8 +343,8 @@ <h3 id="testing">Testing</h3>
<p>Angular provides easy adapters to load modules and use the injector in Jasmine tests.
@@ -366,8 +366,8 @@ to read in source and most importantly, **a pain to modify later**.
```markdown
Fruit | Attribute | Notes
--- | --- | --- | ---
-Apple | [Juicy](http://example.com/SomeReallyReallyReallyReallyReallyReallyReallyReallyLongQuery), Firm, Sweet | Apples keep doctors away.
-Banana | [Convenient](http://example.com/SomeDifferentReallyReallyReallyReallyReallyReallyReallyReallyLongQuery), Soft, Sweet | Contrary to popular belief, most apes prefer mangoes.
+Apple | [Juicy](https://example.com/SomeReallyReallyReallyReallyReallyReallyReallyReallyLongQuery), Firm, Sweet | Apples keep doctors away.
+Banana | [Convenient](https://example.com/SomeDifferentReallyReallyReallyReallyReallyReallyReallyReallyLongQuery), Soft, Sweet | Contrary to popular belief, most apes prefer mangoes.
DO NOT DO THIS
```
@@ -380,15 +380,15 @@ in a slightly less compact, though much more edit-friendly way:
for <em>nonempty</em> blocks and block-like constructs:</p><ul><li>No line break before the opening brace.</li><li>Line break after the opening brace.</li><li>Line break before the closing brace.</li><li>Line break after the closing brace <em>if</em> that brace terminates a statement or the body
of a method, constructor or <em>named</em> class. For example, there is <em>no</em> line break
after the brace if it is followed by <codeclass="prettyprint lang-java">else</code> or a
<h3>6.4 Finalizers: not used <ahref="#s6.4-finalizers"><imgheight="21"width="21"src="javaguidelink.png"/></a></h3>
<p>It is <strong>extremely rare</strong> to override <codeclass="prettyprint lang-java">Object.finalize</code>.</p><pclass="tip"><strong>Tip:</strong> Don't do it. If you absolutely must, first read and understand
@@ -70,7 +70,7 @@ Data should not be arbitrarily grouped for convenience.
<CODE_SNIPPET>
{
"company": "Google",
- "website": "http://www.google.com/",
+ "website": "https://www.google.com/",
"addressLine1": "111 8th Ave",
"addressLine2": "4th Floor",
"state": "NY",
@@ -82,7 +82,7 @@ Data should not be arbitrarily grouped for convenience.
<CODE_SNIPPET>
{
"company": "Google",
- "website": "http://www.google.com/",
+ "website": "https://www.google.com/",
"address": {
"line1": "111 8th Ave",
"line2": "4th Floor",
@@ -292,7 +292,7 @@ public enum Color {
Dates should be formatted as recommended by RFC 3339.
</SUMMARY>
<BODY>
-<p>Dates should be strings formatted as recommended by <ahref="http://www.ietf.org/rfc/rfc3339.txt">RFC 3339</a></p>
+<p>Dates should be strings formatted as recommended by <ahref="https://www.ietf.org/rfc/rfc3339.txt">RFC 3339</a></p>
<CODE_SNIPPET>
{
"lastUpdate": "2007-11-06T16:34:41.000Z"
@@ -306,7 +306,7 @@ Dates should be formatted as recommended by RFC 3339.
Time durations should be formatted as recommended by ISO 8601.
</SUMMARY>
<BODY>
-<p>Time duration values should be strings formatted as recommended by <ahref="http://en.wikipedia.org/wiki/ISO_8601#Durations">ISO 8601</a>.</p>
+<p>Time duration values should be strings formatted as recommended by <ahref="https://en.wikipedia.org/wiki/ISO_8601#Durations">ISO 8601</a>.</p>
<CODE_SNIPPET>
{
// three years, six months, four days, twelve hours,
@@ -322,7 +322,7 @@ Time durations should be formatted as recommended by ISO 8601.
Latitudes/Longitudes should be formatted as recommended by ISO 6709.
</SUMMARY>
<BODY>
-<p>Latitude/Longitude should be strings formatted as recommended by <ahref="http://en.wikipedia.org/wiki/ISO_6709">ISO 6709</a>. Furthermore, they should favor the ±DD.DDDD±DDD.DDDD degrees format.</p>
+<p>Latitude/Longitude should be strings formatted as recommended by <ahref="https://en.wikipedia.org/wiki/ISO_6709">ISO 6709</a>. Furthermore, they should favor the ±DD.DDDD±DDD.DDDD degrees format.</p>
<CODE_SNIPPET>
{
// The latitude/longitude location of the statue of liberty.
@@ -334,7 +334,7 @@ Latitudes/Longitudes should be formatted as recommended by ISO 6709.
</STYLEPOINT>
</CATEGORY>
<CATEGORYtitle="JSON Structure & Reserved Property Names">
-<p>In order to maintain a consistent interface across APIs, JSON objects should follow the structure outlined below. This structure applies to both requests and responses made with JSON. Within this structure, there are certain property names that are reserved for specific uses. These properties are NOT required; in other words, each reserved property may appear zero or one times. But if a service needs these properties, this naming convention is recommend. Here is a schema of the JSON structure, represented in <ahref="http://www.google.com/url?sa=D&q=http%3A%2F%2Forderly-json.org%2F">Orderly</a> format (which in turn can be compiled into a <ahref="http://www.google.com/url?sa=D&q=http%3A%2F%2Fjson-schema.org%2F">JSONSchema</a>). You can few examples of the JSON structure at the end of this guide.</p>
+<p>In order to maintain a consistent interface across APIs, JSON objects should follow the structure outlined below. This structure applies to both requests and responses made with JSON. Within this structure, there are certain property names that are reserved for specific uses. These properties are NOT required; in other words, each reserved property may appear zero or one times. But if a service needs these properties, this naming convention is recommend. Here is a schema of the JSON structure, represented in <ahref="https://www.google.com/url?sa=D&q=http%3A%2F%2Forderly-json.org%2F">Orderly</a> format (which in turn can be compiled into a <ahref="https://www.google.com/url?sa=D&q=http%3A%2F%2Fjson-schema.org%2F">JSONSchema</a>). You can few examples of the JSON structure at the end of this guide.</p>
<CODE_SNIPPET>
object {
string apiVersion?;
@@ -412,12 +412,12 @@ Property Value Type: string<br />Parent: -
<BODY>
<p>Client sets this value and server echos data in the response. This is useful in JSON-P and batch situations , where the user can use the <code>context</code> to correlate responses with requests. This property is a top-level property because the <code>context</code> should present regardless of whether the response was successful or an error. <code>context</code> differs from <code>id</code> in that <code>context</code> is specified by the user while <code>id</code> is assigned by the service.</p><p>Example:</p><p>Request #1:</p>
<CODE_SNIPPET>
-http://www.google.com/myapi?context=bart
+https://www.google.com/myapi?context=bart
</CODE_SNIPPET>
<p>Request #2:</p>
<CODE_SNIPPET>
-http://www.google.com/myapi?context=lisa
+https://www.google.com/myapi?context=lisa
</CODE_SNIPPET>
<p>Response #1:</p>
@@ -572,7 +572,7 @@ Property Value Type: string<br />Parent: <code>data</code>
Property Value Type: string<br />Parent: <code>data</code>
</SUMMARY>
<BODY>
-<p>Represents the etag for the response. Details about ETags in the GData APIs can be found here: <ahref="http://code.google.com/apis/gdata/docs/2.0/reference.html#ResourceVersioning">http://code.google.com/apis/gdata/docs/2.0/reference.html#ResourceVersioning</a></p><p>Example:</p>
+<p>Represents the etag for the response. Details about ETags in the GData APIs can be found here: <ahref="https://code.google.com/apis/gdata/docs/2.0/reference.html#ResourceVersioning">https://code.google.com/apis/gdata/docs/2.0/reference.html#ResourceVersioning</a></p><p>Example:</p>
@@ -596,7 +596,7 @@ Property Value Type: string<br />Parent: <code>data</code>
Property Value Type: string (formatted as specified in BCP 47)<br />Parent: <code>data (or any child element)</code>
</SUMMARY>
<BODY>
-<p>Indicates the language of the rest of the properties in this object. This property mimics HTML's <code>lang</code> property and XML's <code>xml:lang</code> properties. The value should be a language value as defined in <ahref="http://www.rfc-editor.org/rfc/bcp/bcp47.txt">BCP 47</a>. If a single JSON object contains data in multiple languages, the service is responsible for developing and documenting an appropriate location for the <code>lang</code> property.</p><p>Example:</p>
+<p>Indicates the language of the rest of the properties in this object. This property mimics HTML's <code>lang</code> property and XML's <code>xml:lang</code> properties. The value should be a language value as defined in <ahref="https://www.rfc-editor.org/rfc/bcp/bcp47.txt">BCP 47</a>. If a single JSON object contains data in multiple languages, the service is responsible for developing and documenting an appropriate location for the <code>lang</code> property.</p><p>Example:</p>
<CODE_SNIPPET>
{"data": {
"items": [
@@ -614,7 +614,7 @@ Property Value Type: string (formatted as specified in BCP 47)<br />Parent: <cod
Property Value Type: string (formatted as specified in RFC 3339)<br />Parent: <code>data</code>
</SUMMARY>
<BODY>
-<p>Indicates the last date/time (<ahref="http://www.ietf.org/rfc/rfc3339.txt">RFC 3339</a>) the item was updated, as defined by the service.</p><p>Example:</p>
+<p>Indicates the last date/time (<ahref="https://www.ietf.org/rfc/rfc3339.txt">RFC 3339</a>) the item was updated, as defined by the service.</p><p>Example:</p>
<CODE_SNIPPET>
{"data": {"updated": "2007-11-06T16:34:41.000Z"}}
@@ -737,7 +737,7 @@ Property Value Type: string<br />Parent: <code>data</code>
@@ -1054,7 +1054,7 @@ Property Value Type: string<br />Parent: <code>error.errors</code>
<CATEGORYtitle="Examples">
<STYLEPOINTtitle="YouTube JSON API">
<SUMMARY>
-Here's an example of the YouTube JSON API's response object. You can learn more about YouTube's JSON API here: <ahref="http://code.google.com/apis/youtube/2.0/developers_guide_jsonc.html">http://code.google.com/apis/youtube/2.0/developers_guide_jsonc.html</a>.
+Here's an example of the YouTube JSON API's response object. You can learn more about YouTube's JSON API here: <ahref="https://code.google.com/apis/youtube/2.0/developers_guide_jsonc.html">https://code.google.com/apis/youtube/2.0/developers_guide_jsonc.html</a>.
</SUMMARY>
<BODY>
<CODE_SNIPPET>
@@ -1081,16 +1081,16 @@ Here's an example of the YouTube JSON API's response object. You can learn more
@@ -1149,7 +1149,7 @@ This example demonstrates how the Google search items could be represented as a
A list of reserved JavaScript words that should be avoided in property names.
</SUMMARY>
<BODY>
-<p>The words below are reserved by the JavaScript language and cannot be referred to using dot notation. The list represents best knowledge of keywords at this time; the list may change or vary based on your specific execution environment.</p><p>From the <ahref="http://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Fstandards%2FEcma-262.htm">ECMAScript Language Specification 5th Edition</a></p>
+<p>The words below are reserved by the JavaScript language and cannot be referred to using dot notation. The list represents best knowledge of keywords at this time; the list may change or vary based on your specific execution environment.</p><p>From the <ahref="https://www.google.com/url?sa=D&q=http%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Fstandards%2FEcma-262.htm">ECMAScript Language Specification 5th Edition</a></p>
<BAD_CODE_SNIPPET>
abstract
boolean break byte
@@ -1175,7 +1175,7 @@ yield
<HR/>
<palign="center">
-Except as otherwise <ahref="http://code.google.com/policies.html">noted</a>, the content of this page is licensed under the <ahref="http://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0 License</a>, and code samples are licensed under the <ahref="http://www.apache.org/licenses/LICENSE-2.0">Apache 2.0 License</a>.
+Except as otherwise <ahref="https://code.google.com/policies.html">noted</a>, the content of this page is licensed under the <ahref="https://creativecommons.org/licenses/by/3.0/">Creative Commons Attribution 3.0 License</a>, and code samples are licensed under the <ahref="https://www.apache.org/licenses/LICENSE-2.0">Apache 2.0 License</a>.
Naming rules are very important in maintainable code. Objective-C method
names tend to be very long, but this has the benefit that a block of code
can almost read like prose, thus rendering many comments unnecessary. </p>
- <p> When writing pure Objective-C code, we mostly follow standard <ahref="http://developer.apple.com/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html">Objective-C
+ <p> When writing pure Objective-C code, we mostly follow standard <ahref="https://developer.apple.com/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html">Objective-C
naming rules</a>. These naming guidelines may differ
significantly from those outlined in the C++ style guide. For example,
Google's C++ style guide recommends the use of underscores between words
@@ -625,7 +625,7 @@ Revision 2.59
</p>
<p>
Any class, category, method, or variable name may use all capitals for
within the name. This follows Apple's standard of using all capitals
within a name for initialisms such as URL, TIFF, and EXIF.
</p>
@@ -807,7 +807,7 @@ Revision 2.59
The method name should read like a sentence if possible, meaning you
should choose parameter names that flow with the method name. (e.g.
<code>convertPoint:fromRect:</code> or
- <code>replaceCharactersInRange:withString:</code>). See <ahref="http://developer.apple.com/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html#//apple_ref/doc/uid/20001282-BCIGIJJF">Apple's
+ <code>replaceCharactersInRange:withString:</code>). See <ahref="https://developer.apple.com/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html#//apple_ref/doc/uid/20001282-BCIGIJJF">Apple's
Guide to Naming Methods</a> for more details.
</p>
<p>
@@ -1189,7 +1189,7 @@ Revision 2.59
</CODE_SNIPPET>
<p>
If you are using Objective-C 2.0, you should instead declare your
- private category using a <ahref="http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_5.html#">class
+ private category using a <ahref="https://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_5.html#">class
-Google XML Document Format Style Guide</h1><div style="text-align: center;">Version 1.0<br>Copyright Google 2008<br><br></div><h2>Introduction</h2>This document provides a set of guidelines for general use when designing new XML document formats (and to some extent XML documents as well; see Section 11). Document formats usually include both formal parts (DTDs, schemas) and parts expressed in normative English prose.<br><br>These guidelines apply to new designs, and are not intended to force retroactive changes in existing designs. When participating in the creation of public or private document format designs, the guidelines may be helpful but should not control the group consensus.<br><br>This guide is meant for the design of XML that is to be generated and consumed by machines rather than human beings. Its rules are <i>not applicable</i> to formats such as XHTML (which should be formatted as much like HTML as possible) or ODF which are meant to express rich text. A document that includes embedded content in XHTML or some other rich-text format, but also contains purely machine-interpretable portions, SHOULD follow this style guide for the machine-interpretable portions. It also does not affect XML document formats that are created by translations from proto buffers or through some other type of format.<br><br>Brief rationales have been added to most of the guidelines. They are maintained in the same document in hopes that they won't get out of date, but they are not considered normative.<br><br>The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in this document in the sense of <a title="RFC 2119" href="http://www.ietf.org/rfc/rfc2119.txt" id="iecm">RFC 2119.</a><br> <br><h2>1. To design or not to design, that is the question<br></h2><ol><li>Attempt to reuse existing XML formats whenever possible, especially those which allow extensions. Creating an entirely new format should be done only with care and consideration; read <a title="Tim Bray's warnings" href="http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages" id="d3cy">Tim Bray's warnings</a> first. Try to get wide review of your format, from outside your organization as well, if possible. [<i>Rationale:</i> New document formats have a cost: they must be reviewed, documented, and learned by users.]<br><br></li><li>If you are reusing or extending an existing format, make <i>sensible</i>
+Google XML Document Format Style Guide</h1><div style="text-align: center;">Version 1.0<br>Copyright Google 2008<br><br></div><h2>Introduction</h2>This document provides a set of guidelines for general use when designing new XML document formats (and to some extent XML documents as well; see Section 11). Document formats usually include both formal parts (DTDs, schemas) and parts expressed in normative English prose.<br><br>These guidelines apply to new designs, and are not intended to force retroactive changes in existing designs. When participating in the creation of public or private document format designs, the guidelines may be helpful but should not control the group consensus.<br><br>This guide is meant for the design of XML that is to be generated and consumed by machines rather than human beings. Its rules are <i>not applicable</i> to formats such as XHTML (which should be formatted as much like HTML as possible) or ODF which are meant to express rich text. A document that includes embedded content in XHTML or some other rich-text format, but also contains purely machine-interpretable portions, SHOULD follow this style guide for the machine-interpretable portions. It also does not affect XML document formats that are created by translations from proto buffers or through some other type of format.<br><br>Brief rationales have been added to most of the guidelines. They are maintained in the same document in hopes that they won't get out of date, but they are not considered normative.<br><br>The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are used in this document in the sense of <a title="RFC 2119" href="https://www.ietf.org/rfc/rfc2119.txt" id="iecm">RFC 2119.</a><br> <br><h2>1. To design or not to design, that is the question<br></h2><ol><li>Attempt to reuse existing XML formats whenever possible, especially those which allow extensions. Creating an entirely new format should be done only with care and consideration; read <a title="Tim Bray's warnings" href="https://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages" id="d3cy">Tim Bray's warnings</a> first. Try to get wide review of your format, from outside your organization as well, if possible. [<i>Rationale:</i> New document formats have a cost: they must be reviewed, documented, and learned by users.]<br><br></li><li>If you are reusing or extending an existing format, make <i>sensible</i>
use of the prescribed elements and attributes, especially any that are
required. Don't completely repurpose them, but do try to see how they
namespace. Using a default namespace improves readability.]<br><br></li><li>Attribute
names SHOULD NOT be in a namespace unless they are drawn from a foreign
document type or are meant to be used in foreign document types. [<i>Rationale:</i> Attribute names in a namespace must always have a prefix, which is annoying to type and hard to read.]<br><br>
-</li><li>Namespace names are HTTP URIs. Namespace names SHOULD take the form <spanstyle="font-family: Courier New;">http://example.com/</span><istyle="font-family: Courier New;">whatever</i><spanstyle="font-family: Courier New;">/</span><i><spanstyle="font-family: Courier New;">year</span>, </i>where <i>whatever</i> is a unique value based on the name of the document type, and <i>year</i>
+</li><li>Namespace names are HTTP URIs. Namespace names SHOULD take the form <spanstyle="font-family: Courier New;">https://example.com/</span><istyle="font-family: Courier New;">whatever</i><spanstyle="font-family: Courier New;">/</span><i><spanstyle="font-family: Courier New;">year</span>, </i>where <i>whatever</i> is a unique value based on the name of the document type, and <i>year</i>
is the year the namespace was created. There may be additional URI-path parts
before the <i>year.</i> [<i>Rationale:</i> Existing convention. Providing the year allows for the possible recycling of code names.]<br><br></li><li>Namespaces MUST NOT be changed unless the semantics of particular elements or attributes has changed in drastically incompatible ways. [<i>Rationale:</i> Changing the namespace requires changing all client code.]<br><br></li><li>Namespace prefixes SHOULD be short (but not so short that they are likely to be conflict with another project). Single-letter prefixes MUST NOT be used. Prefixes SHOULD contain only lower-case ASCII letters. [<i>Rationale:</i> Ease of typing and absence of encoding compatibility problems.]</li></ol><br>
7. Values</h2><ol><li>Numeric values SHOULD be 32-bit signed integers, 64-bit signed integers, or 64-bit IEEE doubles, all expressed in base 10. These correspond to the XML Schema types <spanstyle="font-family: Courier New;">xsd:int</span>, <spanstyle="font-family: Courier New;">xsd:long</span>, and <spanstyle="font-family: Courier New;">xsd:double</span> respectively. If required in particular cases, <spanstyle="font-family: Courier New;">xsd:integer</span> (unlimited-precision integer) values MAY also be used. [<i>Rationale:</i> There are far too many numeric types in XML Schema: these provide a reasonable subset.] <br><br></li><li>
-Boolean values SHOULD NOT be used (use enumerations instead). If they must be used, they MUST be expressed as <spanstyle="font-family: Courier New;">true</span> or <spanstyle="font-family: Courier New;">false</span>, corresponding to a subset of the XML Schema type <spanstyle="font-family: Courier New;">xsd:boolean</span>. The alternative <spanstyle="font-family: Courier New;">xsd:boolean</span> values <spanstyle="font-family: Courier New;">1</span> and <spanstyle="font-family: Courier New;">0</span> MUST NOT be used. [<i>Rationale:</i> Boolean arguments are not extensible. The additional flexibility of allowing numeric values is not abstracted away by any parser.]<br><br></li><li>Dates should be represented using <atitle="RFC 3339"href="http://www.ietf.org/rfc/rfc3339.txt"id="sk98">RFC 3339</a> format, a subset of both
+Boolean values SHOULD NOT be used (use enumerations instead). If they must be used, they MUST be expressed as <spanstyle="font-family: Courier New;">true</span> or <spanstyle="font-family: Courier New;">false</span>, corresponding to a subset of the XML Schema type <spanstyle="font-family: Courier New;">xsd:boolean</span>. The alternative <spanstyle="font-family: Courier New;">xsd:boolean</span> values <spanstyle="font-family: Courier New;">1</span> and <spanstyle="font-family: Courier New;">0</span> MUST NOT be used. [<i>Rationale:</i> Boolean arguments are not extensible. The additional flexibility of allowing numeric values is not abstracted away by any parser.]<br><br></li><li>Dates should be represented using <atitle="RFC 3339"href="https://www.ietf.org/rfc/rfc3339.txt"id="sk98">RFC 3339</a> format, a subset of both
ISO 8601 format and XML Schema <spanstyle="font-family: Courier New;">xsd:dateTime</span> format. UTC times SHOULD be used rather than local times.
[<i>Rationale:</i> There are far too many date formats and time zones, although it is recognized that sometimes local time preserves important information.]<br><br></li><li>Embedded syntax in character content and attribute values SHOULD NOT be
-Simple key-value pairs SHOULD be represented with an empty element whose name represents the key, with the <spanstyle="font-family: Courier New;">value</span> attribute containing the value. Elements that have a <spanstyle="font-family: Courier New;">value</span> attribute MAY also have a <spanstyle="font-family: Courier New;">unit</span> attribute to specify the unit of a measured value. For physical measurements, the <atitle="SI system"href="http://en.wikipedia.org/wiki/International_System_of_Units"id="rhxg">SI system</a> SHOULD be used. [<i>Rationale:</i>
+Simple key-value pairs SHOULD be represented with an empty element whose name represents the key, with the <spanstyle="font-family: Courier New;">value</span> attribute containing the value. Elements that have a <spanstyle="font-family: Courier New;">value</span> attribute MAY also have a <spanstyle="font-family: Courier New;">unit</span> attribute to specify the unit of a measured value. For physical measurements, the <atitle="SI system"href="https://en.wikipedia.org/wiki/International_System_of_Units"id="rhxg">SI system</a> SHOULD be used. [<i>Rationale:</i>
Simplicity and design consistency. Keeping the value in an attribute
hides it from the user, since displaying just the value without the key is not useful.]<br><br></li><li>If the number of possible keys is very large or unbounded, key-value pairs MAY be represented by a single generic element with <spanstyle="font-family: Courier New;">key</span>, <spanstyle="font-family: Courier New;">value</span>, and optional <spanstyle="font-family: Courier New;">unit</span> and <spanstyle="font-family: Courier New;">scheme</span>
-Sensible schema languages, meaning RELAX NG and Schematron, treat elements and attributes symmetrically. Older and cruder<ahref="http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/"id="h2c3"title="XML Schema"> </a>schema languages such as DTDs and XML Schema, tend to have better support for elements.
+Sensible schema languages, meaning RELAX NG and Schematron, treat elements and attributes symmetrically. Older and cruder<ahref="https://www.w3.org/TR/2004/REC-xmlschema-0-20041028/"id="h2c3"title="XML Schema"> </a>schema languages such as DTDs and XML Schema, tend to have better support for elements.
<br><br></p></li><li>If a piece of data is very large, use an element so that its content can be streamed.<br><br></li>
<li>
<p>
-If a piece of data is in a natural language, put it in an element so you can use the <spanstyle="font-family: Courier New;">xml:lang</span> attribute to label the language being used. Some kinds of natural-language text, like Japanese, often make use <ahref="http://www.w3.org/TR/2001/REC-ruby-20010531"id="pa2f"title="annotations">annotations</a> that are conventionally represented using child elements; right-to-left languages like Hebrew and Arabic may similarly require child elements to manage <ahref="http://www.w3.org/TR/2001/REC-ruby-20010531"id="ehyv"title="bidirectionality">bidirectionality</a> properly.
+If a piece of data is in a natural language, put it in an element so you can use the <spanstyle="font-family: Courier New;">xml:lang</span> attribute to label the language being used. Some kinds of natural-language text, like Japanese, often make use <ahref="https://www.w3.org/TR/2001/REC-ruby-20010531"id="pa2f"title="annotations">annotations</a> that are conventionally represented using child elements; right-to-left languages like Hebrew and Arabic may similarly require child elements to manage <ahref="https://www.w3.org/TR/2001/REC-ruby-20010531"id="ehyv"title="bidirectionality">bidirectionality</a> properly.
herrjemand
committed
0 comments on commit
7969290