Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set index for SEMANTIC #1

Closed
fabrobinet opened this issue Mar 14, 2013 · 7 comments
Closed

Set index for SEMANTIC #1

fabrobinet opened this issue Mar 14, 2013 · 7 comments

Comments

@fabrobinet
Copy link
Contributor

Currently we have a couple of { semantic, set }.

Patrick suggested we could use a parsing convention like "semantic.set" so that we get a single property. Some implementation experiments and/or community feedback welcomed before changing this.

@pjcozzi
Copy link
Member

pjcozzi commented Mar 14, 2013

A bit more details from our discussion:

The COLLADA solution is to introduce a new property, set, to uniquely identify an attribute. Although this keeps the semantic property clean and well defined, it also requires the client-side implementation to carry around two properties to link attributes from primitive to program. It seems more concise and convenient to have unique semantics, e.g,

"TEXCOORD.0"
"TEXCOORD.1",
"TEXCOORD.2"

We can define the semantic string format as "SemanticName[.OptionalUniqueIndex]."

and

We can look at it like this: there is pain either because

  1. We have to manage two properties: semantic and set
  2. We have to parse semantic

For rendering uses cases, (2) is less frequent than (1) so I prefer (2). My renderer doesn't need (2). Also, (2) requires less overall code. (1) is just a one-liner if needed.

@ghost ghost assigned fabrobinet Mar 15, 2013
@fabrobinet
Copy link
Contributor Author

I asked for advice from web developers. using "." character in JSON is not good practice, same for "-" , only "_" seems safe.
It is technically possible to handle "." but it might appear not right for a JSON SPEC.

@tparisi
Copy link
Contributor

tparisi commented Mar 15, 2013

what about "/" or "," , not good?

"_" is ok by me. Are we already using that anywhere in our reserved
identifiers?

Tony

On Thu, Mar 14, 2013 at 5:59 PM, Fabrice Robinet
notifications@github.comwrote:

I asked for advice from web developers. using "." character in JSON is not
good practice, same for "-" , only "_" seems safe.
It is technically possible to handle "." but it might appear not right for
a JSON SPEC.


Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-14938621
.

Tony Parisi tparisi@gmail.com
CTO at Large 415.902.8002
Skype auradeluxe
Follow me on Twitter! http://twitter.com/auradeluxe
Read my blog at http://www.tonyparisi.com/

Read my book! WebGL, Up and Running
http://shop.oreilly.com/product/0636920024729.do
http://www.amazon.com/dp/144932357X

@pjcozzi
Copy link
Member

pjcozzi commented Mar 15, 2013

I'm OK with "_", but why is "." a bad idea? It is inside a string literal; we should be able to do whatever we want.

@fabrobinet
Copy link
Contributor Author

Yes, but is usually not recommended because they need to access a property like this obj['prop'] and can't do obj.prop in that case, which is what people tend to like more.

To be honest I would really prefer "." I just don't want to upset JS purists here :).

@pjcozzi
Copy link
Member

pjcozzi commented Mar 15, 2013

Gotcha. This is a non-issue for "semantic" : "name.index"; however, I see that it is an issue for "name.index" : { whatever }.

I'm OK with "_".

@fabrobinet
Copy link
Contributor Author

That is pushed. Closing.

@fabrobinet fabrobinet removed their assignment Mar 19, 2015
lexaknyazev pushed a commit that referenced this issue Nov 17, 2016
* Upgrade to json schema v4 syntax

* More allOf changes
pjcozzi pushed a commit that referenced this issue Jul 25, 2017
emackey pushed a commit that referenced this issue Jan 31, 2020
Added Datakit CrossCad/Ware SDK
emackey pushed a commit that referenced this issue Feb 4, 2020
emackey pushed a commit that referenced this issue May 28, 2020
…ancing

Rename KHR_mesh_instancing -> EXT_mesh_gpu_instancing
emackey pushed a commit that referenced this issue Aug 6, 2020
aaronfranke pushed a commit to aaronfranke/glTF that referenced this issue Jan 4, 2024
…justments

factors in KHR PR feedback and fixes readme
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants