In the oneM2M HTTP protocol binding spec (TS-0009) it says:
Any of the short names listed in table 6.2.2.2-1, with the exception of ‘atr’, may be used in the query-string. The short name ‘atr’ itself is not used. Instead, any of the resource attribute short names as listed in tables 8.2.3-1 to 8.2.3-5 in oneM2M TS-0004 [3] may be used in the query-string in representations of attname=attvalue expressions...
However, there is no mention of how the key/value pairs in filterCriteria.attribute are supposed to be encoded in a CoAP request (eg, in TS-0008).
Is this specified somewhere?
"atr", ie. the resource attributes in a query, are part of the Filter Criteria (see TS-0004, section 7.3.3.17.9). Filter Criteria elements are encoded in the CoAP uri-query option (see TS-0008, the last paragraph of section "6.2.2.3 URI Options").
See also IETF RFC 7252, section 6.5, which step 8, defines how to encode key/value pairs in the uri-query option.
In Terraform I can use:
name = "${var.names["apple"])"
which looks up the string "apple" in var.names.
However, this syntax would break in most programming languages as it would try and parse "${var.names[" then apple then "])".
I've looked up documentation on this but failed to find anything. Are there any details?
I've read:
https://www.terraform.io/docs/configuration/syntax.html
and
https://www.terraform.io/docs/configuration/interpolation.html
The last link briefly gives an example
template = "${file("templates/web_init.tpl")}"
but doesn't explain.
Upgrade guide to v0.7 explicitly introduces nested quoting context. Apparently this had been allowed since one of the earlier versions, but I could not pinpoint which one exactly.
Followup to this question. Groovy.codehaus.org just refers to it as a token. Are there any informal monikers floating around like 'splat' and 'bang'?
It is informally known as "the arrow". I cite this post from 2008. Though I can't claim it is a standard idiom, I've never heard it called anything else (in conversation).
In the antlr parser script, it's called the 'closable block operator'
I don't know of a snappier name than 'arrow'
I've heard it called "Rocket" before.
Also a "Fat Rocket"/"Hash Rocket" would be '=>'
But this more applies to Ruby lingo.
This is PascalCase: SomeSymbol
This is camelCase: someSymbol
This is snake_case: some_symbol
So my questions is whether there is a widely accepted name for this: some-symbol? It's commonly used in url's.
There isn't really a standard name for this case convention, and there is disagreement over what it should be called.
That said, as of 2019, there is a strong case to be made that kebab-case is winning:
https://trends.google.com/trends/explore?date=all&q=kebab-case,spinal-case,lisp-case,dash-case,caterpillar-case
spinal-case is a distant second, and no other terms have any traction at all.
Additionally, kebab-case has entered the lexicon of several javascript code libraries, e.g.:
https://lodash.com/docs/#kebabCase
https://www.npmjs.com/package/kebab-case
https://v2.vuejs.org/v2/guide/components-props.html#Prop-Casing-camelCase-vs-kebab-case
However, there are still other terms that people use. Lisp has used this convention for decades as described in this Wikipedia entry, so some people have described it as lisp-case. Some other forms I've seen include caterpillar-case, dash-case, and hyphen-case, but none of these is standard.
So the answer to your question is: No, there isn't a single widely-accepted name for this case convention analogous to snake_case or camelCase, which are widely-accepted.
It's referred to as kebab-case. See lodash docs.
It's also sometimes known as caterpillar-case
This is the most famous case and It has many names
kebab-case: It's the name most adopted by official software
caterpillar-case
dash-case
hyphen-case or hyphenated-case
lisp-case
spinal-case
css-case
slug-case
friendly-url-case
As the character (-) is referred to as "hyphen" or "dash", it seems more natural to name this "dash-case", or "hyphen-case" (less frequently used).
As mentioned in Wikipedia, "kebab-case" is also used. Apparently (see answer) this is because the character would look like a skewer... It needs some imagination though.
Used in lodash lib for example.
Recently, "dash-case" was used by
Angular (https://angular.io/guide/glossary#case-types)
NPM modules
https://www.npmjs.com/package/case-dash (removed ?)
https://www.npmjs.com/package/dasherize
Adding the correct link here Kebab Case
which is All lowercase with - separating words.
I've always called it, and heard it be called, 'dashcase.'
There is no standardized name.
Libraries like jquery and lodash refer it as kebab-case. So does Vuejs javascript framework. However, I am not sure whether it's safe to declare that it's referred as kebab-case in javascript world.
I've always known it as kebab-case.
On a funny note, I've heard people call it a SCREAM-KEBAB when all the letters are capitalized.
Kebab Case Warning
I've always liked kebab-case as it seems the most readable when you need whitespace. However, some programs interpret the dash as a minus sign, and it can cause problems as what you think is a name turns into a subtraction operation.
first-second // first minus second?
ten-2 // ten minus two?
Also, some frameworks parse dashes in kebab cased property. For example, GitHub Pages uses Jekyll, and Jekyll parses any dashes it finds in an md file. For example, a file named 2020-1-2-homepage.md on GitHub Pages gets put into a folder structured as \2020\1\2\homepage.html when the site is compiled.
Snake_case vs kebab-case
A safer alternative to kebab-case is snake_case, or SCREAMING_SNAKE_CASE, as underscores cause less confusion when compared to a minus sign.
I'd simply say that it was hyphenated.
Worth to mention from abolish:
https://github.com/tpope/vim-abolish/blob/master/doc/abolish.txt#L152
dash-case or kebab-case
In Salesforce, It is referred as kebab-case. See below
https://developer.salesforce.com/docs/component-library/documentation/lwc/lwc.js_props_names
Here is a more recent discombobulation. Documentation everywhere in angular JS and Pluralsight courses and books on angular, all refer to kebab-case as snake-case, not differentiating between the two.
Its too bad caterpillar-case did not stick because snake_case and caterpillar-case are easily remembered and actually look like what they represent (if you have a good imagination).
My ECMAScript proposal for String.prototype.toKebabCase.
String.prototype.toKebabCase = function () {
return this.valueOf().replace(/-/g, ' ').split('')
.reduce((str, char) => char.toUpperCase() === char ?
`${str} ${char}` :
`${str}${char}`, ''
).replace(/ * /g, ' ').trim().replace(/ /g, '-').toLowerCase();
}
This casing can also be called a "slug", and the process of turning a phrase into it "slugify".
https://hexdocs.pm/slugify/Slug.html
The rules for resolving SIDs in COLLADA, and COLLADA FX SIDs in particular, are not very clear. With regard to COLLADA FX SIDs in particular, how do I know at which element to start the search for a particular SID? Consider, for example, the "texture" atttibute of a <texture> element:
<effect id="Scene_Material_fx">
<profile_COMMON>
<newparam sid="acorn_png_surface">
<surface type="2D">
<init_from>acorn_png_img</init_from>
</surface>
</newparam>
<newparam sid="acorn_png_sampler">
<sampler2D>
<source>acorn_png_surface</source>
</sampler2D>
</newparam>
<technique sid="default">
<phong>
...
<diffuse>
<texture texture="acorn_png_sampler" texcoord="diffuse_TEXCOORD"></texture>
</diffuse>
...
</phong>
</technique>
</profile_COMMON>
</effect>
I can find the SID referenced by <texture> if I start the search at <profile_COMMON>, which is the great-great-grandparent of the <texture> element that contains the reference, but I can also find it if I start searching from <effect>. How, then, is the starting element determined? Is it defined somewhere in the spec?
Does the spec provide a limit to how close to the document root an sid referenced by a particular <texture> element may be found? In the above example, could it possibly appear outside of <profile_COMMON>, such as inside its <effect> parent? Which is the "rootmost" element at which I am guaranteed to find the referenced sid by drilling down from that element?
Update: I have also posted this question in the COLLADA forums, so far with no response. I've decided that, for the time being, I shall simply assume the SID referenced by a <texture>'s "texture" attribute will always be found under <profile_COMMON>. If that's wrong it means my importer may fail on valid input, but the COLLADA community itself has offered no feedback on this so there's nothing I can do.
I can feel your pain ;-). Collada specs are really hard to understand.
As you can have params declared in <effect> scope (not only inside <profile> : Chapter 7 About parameters) you should look there too.
But. Judging from my experience exporters tends to have local params (under <profile>) so your way will work too.
This is an old question, but I believe the answer is that SID's are 'scoped id's' at the level of the parent ID. So you technically begin searching just under the element, and all sids are unique under that block.
That was always my understanding, anyway...