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.

Sign up for GitHub

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

Jump to bottom

In jsonselect in its current form is a huge ideological problem. #41

Open
yokotoka opened this issue Dec 8, 2012 · 0 comments
Open

In jsonselect in its current form is a huge ideological problem. #41

yokotoka opened this issue Dec 8, 2012 · 0 comments

Comments

@yokotoka
Copy link

yokotoka commented Dec 8, 2012

In jsonselect in its current form is a huge ideological problem.

In the query language jsonselect swapped up (or mixed up) the names of the elements and classes.
For example, on page http://jsonselect.org/#tryit selector string.favoriteColor
shows yellow although ideologically correct to favoriteColor.string cause favoriteColor - name of the element, and string - his class (type).
Instead of string can be used number, array, hash, language-pseudotypes etc.

Again, that key to json should act as the names of the and types - as classes.

Take, for example jQuery and HTML DOM.
HTML has elements (such as <a>, <div>, etc.) and attributes of these elements (such as class, rel, src, id)
jQuery uses CSS Selectors. For example, to get the tag <div class="foo2"> in the following code:

<html>
    <head></head>
    <body>
        <div class="bar1">
            <div class="foo1"></div>
        </div>
        <div class="bar2">
            <div class="foo2"></div>
        </div>
    </body>
</html>

We can use the following selectors: div.foo2 or . bar2>. foo2 or body. foo2, etc.

In json have no attributes, such as class. There is only the element names (tags), compared with json html dom.
It would be logical to use the types of classes as values.

In general, if we take the example of page http://jsonselect.org/#tryit, it should be so:

code
.languagesSpoken .lang => languagesSpoken lang
.drinkPreference :first-child => drinkPreference:first-child
.seatingPreference :nth-child(1) seatingPreference:nth-child(1)
."weight" => weight
.lang => lang
.favoriteColor => favoriteColor
string.favoriteColor => favoriteColor.string
string:last-child => .string:last-child
string:nth-child(-n+2) => .string:nth-child(-n+2)
string:nth-child(odd) => .string:nth-child(odd)
string:nth-last-child(1) => .string:nth-last-child(1)
:root => :root
number => .number
:has(:root > .preferred) => :has(:root > preferred)
.preferred ~ .lang => preferred ~ lang
:has(.lang:val("Spanish")) > .level => :has(lang:val("Spanish")) > level
.lang:val("Bulgarian") ~ .level => lang:val("Bulgarian") ~ level
.weight:expr(x<180) ~ .name .first => weight:expr(x<180) ~ name first

In the end, what we have now - like the css selectors with very confused logic.
Urge to release a new edition of the standard, which will take into account this remark and focus on the new version.
Because if taken as a basis jQuery / CSS selectors, you must comply with this idea.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@yokotoka