Hi,
I'm jontools's owner (jontools.sourceforge.net). I'm developing a
library to use json in java but my principal effort is to create an API
to use in java and that any implementation can use (the actual system
works in this way).

I've defined some API yet and I'll want that  the package starts with
org.json (now is it.dangelo). Is it possible or there are limitation?

I would create 3 APIs (for now):

     * SAJ (like SAX) org.json.saj
     * DOM(Json) org.json.dom
     * STaJ (STaX like) org.json.staj


What about?

Hi all,
I've started a new Group to define a common API for json in Java
environment.
You are all invited.

Please help me.

bye

Hi all,
I'm sorry for late, I had some problem to subscribe the group!

First (for tatu): I've released a pdf guide for annotation usage for
jajb, you can find it at http://jajb.sourceforge.net/documentation.html.
Anyway, now I'm here and I can help you all and answer to you question!

Please, alert me for each bugs you'll find, I'll try to solve them
immediatly.

Second (for akaidr4vr): I'm not sure about your question: do you want
to now if jajb can be integrated with cold fusion?



--- In json@yahoogroups.com, Claudio D'angelo <claudio.dangelo@...> wrote:
>
> What?
> Can you explain better?
>
> Thanks
>
> Mark Ireland ha scritto:
> >
> >
> > Do you want to see if it works for ColdFusion?
> >
> > > To: json@yahoogroups.com <mailto:json%40yahoogroups.com>
> > > CC: gabriele.negro1@... <mailto:gabriele.negro1%40tin.it>
> > > From: claudio.dangelo@...
> > <mailto:claudio.dangelo%40lombardia-servizi.it>
> > > Date: Mon, 19 May 2008 08:46:08 +0200
> > > Subject: Re: [json] Sharing Java objects with JavaScript
> > >
> > > Hi Tatu,
> > > you can found the documentation of JAJB in
> > > http://jajb.sourceforge.net/documentation.html
> > <http://jajb.sourceforge.net/documentation.html> (there is a link
to pdf).
> > > In cc there is the project's owner.
> > > If the documentation is not complete please report it to
Gabriele or me.
> > >
> > > JAJB permits to map json in javabean using 3 different ways: xml
> > > mapping, annotation and direct mapping. We have studied jajb to map
> > > (also) java classes that doesn't follow the javabean specification.
> > > I'm available (and I think Gabriele too) to help you with JAJB.
> > >
> > > JAJB depends by SAJ and DOMJson that they are 2 libraries to
parse json
> > > (SAJ is like SAX).
> > > SAJ has a simple support for an old specification of json-schema
that
> > > you can use to validate your json stream. Now we are working to
> > > implement another validation system in SAJ called json-vl (see
> > > http://jontools.sourceforge.net/
<http://jontools.sourceforge.net/>).
> > >
> > >
> > > I and Gabriele works to use json in any data transmission system
(web
> > > rich client and business2business) and we have needed of developers
> > that
> > > supply feedbacks (this help ours projects that use this libraries).
> > >
> > > Claudio
> > >
> > >
> > > Tatu Saloranta ha scritto:
> > > >
> > > > On Thu, May 15, 2008 at 11:38 PM, Claudio D'angelo
> > > > <claudio.dangelo@...
> > <mailto:claudio.dangelo%40lombardia-servizi.it>
> > > > <mailto:claudio.dangelo%40lombardia-servizi.it>> wrote:
> > > >
> > > > Hi Claudio, I was wondering about this:
> > > >
> > > > > * You can also use the JAJB (http://jajb.sourceforg.net
> > <http://jajb.sourceforg.net>
> > > > <http://jajb.sourceforg.net <http://jajb.sourceforg.net>>)
that is a
> > > > > binding system between java and json. You can have in java your
> > > >
> > > > I have been looking for something like this (assuming it does
what it
> > > > should be, i.e. like JAXB, but instead of XML, json). But the
project
> > > > home page seems to be void of content. Do you know where I
could learn
> > > > more about it?
> > > >
> > > > I have been thinking of writing such a binding framework
myself, but
> > > > if a decent one exists, I wouldn't mind saving that time for
something
> > > > else. :-)
> > > >
> > > > Also, related to the original question: there are many data
binding
> > > > tools between Java and JSon.
> > > > In addition to ones mentioned, Jackson JSON processor (at
> > > > http://jackson.codehaus.org/ <http://jackson.codehaus.org/>
> > <http://jackson.codehaus.org/ <http://jackson.codehaus.org/>>) has
> > > > simple mappings from json to either
> > > > Java containers/primitives (List, Maps, Strings, Numbers,
Booleans,
> > > > null), or to DOM-like node-based tree (JsonNode) with path access.
> > > > It does not have bean-bindings, but I am hoping to be able to hook
> > > > Jackson parser to a framework.
> > > > That would be useful for my use case, which requires high
performance,
> > > > and where Jackson's ultra-fast parsing is necessary, but where
> > > > convenience of true data binding would also come in handy. :-)
> > > >
> > > > -+ Tatu +-
> > > >
> > > >
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> >
> > __________________________________________________________
> > Search for local singles online @ Lavalife - Click here
> >
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2\
Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%\
26a%3D30290&_t=764581033&_r=email_taglines_Search_OCT07&_m=EXT

> >
<http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%\
2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU\
%26a%3D30290&_t=764581033&_r=email_taglines_Search_OCT07&_m=EXT>
> >
> > [Non-text portions of this message have been removed]
> >
> >
>

Sorry...
this is the link
http://tech.groups.yahoo.com/group/java_json_api/

I could send you the SAX like API I have built for C++ if
you are interested.   Its pretty simple.

-Mark
P6R, Inc


On Thu, 22 May 2008 09:15:25 +0200
   "Claudio D'angelo"
<claudio.dangelo@...> wrote:
> Hi,
> I'm jontools's owner (jontools.sourceforge.net). I'm
>developing a
> library to use json in java but my principal effort is
>to create an API
> to use in java and that any implementation can use (the
>actual system
> works in this way).
>
> I've defined some API yet and I'll want that  the
>package starts with
> org.json (now is it.dangelo). Is it possible or there
>are limitation?
>
> I would create 3 APIs (for now):
>
>    * SAJ (like SAX) org.json.saj
>    * DOM(Json) org.json.dom
>    * STaJ (STaX like) org.json.staj
>
>
> What about?
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

-------------------------
Mark Joseph, Ph.D.
President and Secretary
P6R, Inc.
http://www.p6r.com
408-205-0361
Fax: 831-476-7490
Skype: markjoseph_sc
IM: (Yahoo) mjoseph8888
      (AIM) mjoseph8888

Yes,
I can taking the cue from your implementation too.
Can you help me for the language? I don't know very well the C++.

Thanks

P.S. : If you want, you can join to the group to add value.




Mark Joseph ha scritto:
> I could send you the SAX like API I have built for C++ if
> you are interested.   Its pretty simple.
>
> -Mark
> P6R, Inc
>
>
> On Thu, 22 May 2008 09:15:25 +0200
>   "Claudio D'angelo"
> <claudio.dangelo@...> wrote:
>
>> Hi,
>> I'm jontools's owner (jontools.sourceforge.net). I'm
>> developing a
>> library to use json in java but my principal effort is
>> to create an API
>> to use in java and that any implementation can use (the
>> actual system
>> works in this way).
>>
>> I've defined some API yet and I'll want that  the
>> package starts with
>> org.json (now is it.dangelo). Is it possible or there
>> are limitation?
>>
>> I would create 3 APIs (for now):
>>
>>    * SAJ (like SAX) org.json.saj
>>    * DOM(Json) org.json.dom
>>    * STaJ (STaX like) org.json.staj
>>
>>
>> What about?
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>
> -------------------------
> Mark Joseph, Ph.D.
> President and Secretary
> P6R, Inc.
> http://www.p6r.com
> 408-205-0361
> Fax: 831-476-7490
> Skype: markjoseph_sc
> IM: (Yahoo) mjoseph8888
>      (AIM) mjoseph8888
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>

Sure sounds good I will join the group.   I think I will
publish the API on our site at:

http://www.p6r.com/articles/

In the next day or two.

Best,
Mark
P6R, Inc


On Thu, 22 May 2008 16:03:14 +0200
   "Claudio D'angelo"
<claudio.dangelo@...> wrote:
> Yes,
> I can taking the cue from your implementation too.
> Can you help me for the language? I don't know very well
>the C++.
>
> Thanks
>
> P.S. : If you want, you can join to the group to add
>value.
>
>
>
>
> Mark Joseph ha scritto:
>> I could send you the SAX like API I have built for C++
>>if
>> you are interested.   Its pretty simple.
>>
>> -Mark
>> P6R, Inc
>>
>>
>> On Thu, 22 May 2008 09:15:25 +0200
>>   "Claudio D'angelo"
>> <claudio.dangelo@...> wrote:
>>
>>> Hi,
>>> I'm jontools's owner (jontools.sourceforge.net). I'm
>>> developing a
>>> library to use json in java but my principal effort is
>>> to create an API
>>> to use in java and that any implementation can use (the
>>> actual system
>>> works in this way).
>>>
>>> I've defined some API yet and I'll want that  the
>>> package starts with
>>> org.json (now is it.dangelo). Is it possible or there
>>> are limitation?
>>>
>>> I would create 3 APIs (for now):
>>>
>>>    * SAJ (like SAX) org.json.saj
>>>    * DOM(Json) org.json.dom
>>>    * STaJ (STaX like) org.json.staj
>>>
>>>
>>> What about?
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>
>> -------------------------
>> Mark Joseph, Ph.D.
>> President and Secretary
>> P6R, Inc.
>> http://www.p6r.com
>> 408-205-0361
>> Fax: 831-476-7490
>> Skype: markjoseph_sc
>> IM: (Yahoo) mjoseph8888
>>      (AIM) mjoseph8888
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

-------------------------
Mark Joseph, Ph.D.
President and Secretary
P6R, Inc.
http://www.p6r.com
408-205-0361
Fax: 831-476-7490
Skype: markjoseph_sc
IM: (Yahoo) mjoseph8888
      (AIM) mjoseph8888

On Tue, May 20, 2008 at 12:31 PM, Douglas Crockford
<douglas@...> wrote:
> --- In json@yahoogroups.com, "Peter Michaux" <petermichaux@...> wrote:
>> This file modifies the built in Data.prototype object. In many
>
> circles modifying
>> objects you don't own is considered a sin. I agree with that
>> sentiment.
>
> I don't. Augmentation of the core objects is one of the places where
> we can effectively repair the language.

I think it would be difficult to argue that the language is broken in
this case. It simply does not have a particular method.

Peter

Here is a description of our working API

"A SAX-like parser for JSON"
http://www.p6r.com/articles/2008/05/22/a-sax-like-parser-for-json/

I just put it up today.

Best,
Mark
P6R, Inc




On Thu, 22 May 2008 16:03:14 +0200
   "Claudio D'angelo"
<claudio.dangelo@...> wrote:
> Yes,
> I can taking the cue from your implementation too.
> Can you help me for the language? I don't know very well
>the C++.
>
> Thanks
>
> P.S. : If you want, you can join to the group to add
>value.
>
>
>
>
> Mark Joseph ha scritto:
>> I could send you the SAX like API I have built for C++
>>if
>> you are interested.   Its pretty simple.
>>
>> -Mark
>> P6R, Inc
>>
>>
>> On Thu, 22 May 2008 09:15:25 +0200
>>   "Claudio D'angelo"
>> <claudio.dangelo@...> wrote:
>>
>>> Hi,
>>> I'm jontools's owner (jontools.sourceforge.net). I'm
>>> developing a
>>> library to use json in java but my principal effort is
>>> to create an API
>>> to use in java and that any implementation can use (the
>>> actual system
>>> works in this way).
>>>
>>> I've defined some API yet and I'll want that  the
>>> package starts with
>>> org.json (now is it.dangelo). Is it possible or there
>>> are limitation?
>>>
>>> I would create 3 APIs (for now):
>>>
>>>    * SAJ (like SAX) org.json.saj
>>>    * DOM(Json) org.json.dom
>>>    * STaJ (STaX like) org.json.staj
>>>
>>>
>>> What about?
>>>
>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>
>> -------------------------
>> Mark Joseph, Ph.D.
>> President and Secretary
>> P6R, Inc.
>> http://www.p6r.com
>> 408-205-0361
>> Fax: 831-476-7490
>> Skype: markjoseph_sc
>> IM: (Yahoo) mjoseph8888
>>      (AIM) mjoseph8888
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

-------------------------
Mark Joseph, Ph.D.
President and Secretary
P6R, Inc.
http://www.p6r.com
408-205-0361
Fax: 831-476-7490
Skype: markjoseph_sc
IM: (Yahoo) mjoseph8888
      (AIM) mjoseph8888

On Sat, May 24, 2008 at 2:46 PM, Douglas Crockford
<douglas@...> wrote:
> On Sat, May 24, 2008 at 2:37 PM, Collin Jackson <collin@...>
wrote:
> > Can we change the name of JSONRequest's Domain header to also be
> > Origin and have its behavior match XHR2 and postMessage? This will
> > allow servers to enforce security policies based on scheme and port
> > [2].
>
> > Yes. Send me the formal text and I will update the doc.

Here is a version that doesn't reference any specs. Alternatively, you
could reference either the HTML 5 specification
<http://www.whatwg.org/specs/web-apps/current-work/multipage/section-origin.html\
">
or the Access-Control specification
<http://www.w3.org/TR/access-control/#access-control-origin>.

<h3><code>Origin</code></h3>

The <code>Origin</code> is the serialization of the security origin of
the page from which the request is issued. It can be used by the
server when deciding to allow the request. It is the scheme followed
by <code>://</code>, followed by the original
<code>document.domain</code> without any trailing U+002E (.), if any,
where each part of the domain has had the IDNA ToASCII algorithm
applied. Then, if port is not the default port for the scheme, follow
it by <code>:</code> and the port. If the source of the request does
not have a host-based authority, the access control origin is the
literal string "null" (without the quotation marks).

To: douglas@...

Douglas Crockford,

Why did you not include the 'undefined' literal in the JSON grammar at
JSON.org?

Afaics, it does not violate any of JSON's objectives (including the
security objectives for JSONrequest), and is an important data state
that needs to be included in order to cover the widest range of
possible data structures.

Perhaps you are not aware that the 'in' operator in JavaScript does
recognize the existence of an object property with an undefined value,
until it has been removed with the delete operator:

http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Operators:Spe\
cial_Operators:in_Operator#Using_in_with_deleted_or_undefined_properties

Thus, there is a way to detect which properties were defined in JSON
with this proposed undefined literal.  Simply test with 'in' operator.

I assume your mistake was you erroneously assumed that undefined would
be undetectable in the equivalent JavaScript object.

It would break quite a bit of JavaScript code to include the undefined
literal now, e.g. all if( !object.property ) or if( object.property
=== undefined ) or if( typeof object.property == 'undefined' ) would
need to be converted to if( property in object ).


--

Kind Regards,
Shelby Moore
http://coolpage.com

On Sun, May 25, 2008 at 8:54 AM, Shelby Moore <shelby@...> wrote:
> To: douglas@...
>
> Douglas Crockford,
>
> Why did you not include the 'undefined' literal in the JSON grammar at
> JSON.org?
>
> Afaics, it does not violate any of JSON's objectives (including the
> security objectives for JSONrequest),

It violates the objective of being a language-neutral format that is
friendly to several existing languages. JSON, as is, is already a
subset of Python and YAML as well as JavaScript. For many other
languages, there's usually a simple mapping from JSON to existing
concepts of that language. Many languages have a null. Few have a
distinct undefined.


> and is an important data state
> that needs to be included in order to cover the widest range of
> possible data structures.

It is not a goal to be able to directly represent "the widest range of
possible...".


> Perhaps you are not aware that the 'in' operator in JavaScript does
> recognize the existence of an object property with an undefined value,
> until it has been removed with the delete operator:

I can assure you that Crock is quite aware of this ;)


--
     Cheers,
     --MarkM

Douglas Crockford wrote:
>
> JSON was intended to be language independent. Most languages have or
> tolerate
> the idea of a null value. Very few languages have two of them.

Wow, thanks for the quick reply.  Other than the legacy issue I
pointed out in my prior message, could I perhaps change your mind?

Afaics, neither C or C++ have a null datatype (C also no bool).
Either must tag all values with an enum(eration) of value types, or
use (void*)0 for null. Enum tagging could handle another datatype, or
use (void**)0.  Classes in C++ don't help, because there is no typeof.
Or perhaps could use operator overloading in C++ with a class to
detect instances of that class.

It seems most all languages either fall into the above scenario of
simulating null (and thus could simulate undefined), or the modern
non-prototype 00 languges have a means for detecting the class of an
object, so then use new Undefined().  Afaik, even Java's Null type is
just a class.

I am working on an implicit schema for JSON (to enable Web 3.0
decentralized mashups) and I am thinking of declaring undefined to be
a legal value and usurp your defacto standard.  Could you please steer
me otherwise with further logic?

Again thanks a lot for the feedback.

Mark S. Miller scripsit:

> It violates the objective of being a language-neutral format that is
> friendly to several existing languages. JSON, as is, is already a
> subset of Python

To pick a nit:

I see this claim pretty often, but it is not really true:  Python's
null is spelled "None".  You can make a global definition "null=None"
for input purposes, but Python's output will still generate "None"
rather than "null", as well as outputting single quotes rather than
JSON's double quotes.

--
With techies, I've generally found              John Cowan
If your arguments lose the first round          http://www.ccil.org/~cowan
     Make it rhyme, make it scan                 cowan@...
     Then you generally can
Make the same stupid point seem profound!           --Jonathan Robie

I have modified one of the regular expressions in the JSON.parse
method to more reliably signal a syntax error in the case of a
malformed \uHHHH string. No security exploit existed or was repaired
by this change.

http://json.org/json2.js

--- In json@yahoogroups.com, "Shelby Moore" <shelby@...> wrote:
> I am working on an implicit schema for JSON (to enable Web 3.0
> decentralized mashups) and I am thinking of declaring undefined to be
> a legal value and usurp your defacto standard.  Could you please steer
> me otherwise with further logic?

JSON will not be extended to include undefined. Your options are to
either accept the definition of JSON as it is, or to create your own
format. If you do the latter, please don't call it JSON.

"Douglas Crockford" <douglas@...> wrote:
> JSON will not be extended to include undefined. Your options are to
> either accept the definition of JSON as it is, or to create your own
> format. If you do the latter, please don't call it JSON.

Thanks again for reply.

Viability of JSON's strength as unchanging specification, will depend
on the correctness and minimal completeness of it's primitives model.
Agree with your goal, but want to hash out the primitive "sweet spot".

RFC 4627 for JSON states:

"It is derived from the object literals of JavaScript, as defined in
the ECMAScript Programming Language Standard, Third Edition [ECMA]"

ECMA-262 specifies a Type and Value for Undefined, but granted it does
not specify a literal for undefined. I.e. Undefined can be create in
execution context, but not in literal assignment.

What is not clear to me is when did the identifier, undefined, become
an assignable global object?  Mozilla claims JavaScript 1.3 and ECMA-262:

http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Proper\
ties:undefined

If true, then treating undefined as a literal in JSON, is compatible
with ECMA-262. And my prior posts have argued no additional
portability burden for an undefined literal (other than the legacy
issue of current RFC 4627 grammar).

JSON excels in efficiency and simplicity over orthogonal schema
formats, e.g. XML, in data structures where the data is also
implicitly the schema. Undefined is a necessary semantic in schema,
because robust construction of data structures via inheritance
requires both a "required type of fillable value" (i.e. Null) and an
"optional type" (i.e. Undefined). Undefined is not the same as
"unknown or any type". Without an undefined literal, my best
workaround so far is to resort to stealing the empty array from it's
true semantic, to give it undefined semantic.

After we determine what is primitively correct, then we deal with
legacy implementations and naming. Market efficiency often decides to
retain a popular name, with legacy qualification. I suspect the market
would choose "JSON2" or "JSON+" over some entirely new name?

Since my new (unreleased) proposal for implicit JSON schemas, could
refer to "JSON+undefined" since there are no legacy parsers of my
specification. And my first implementation in JavaScript utilizes
cross-domain dynamic <script> tags for loading, because
de-centralization is entirely the point of Web 3.0. Afaik, JSONRequest
is not yet widely adopted, so use of my proposal could possibly drive
adoption of a "JSON+Request".

Patents & copyrights (like all socialism insurance contracts) are
unsustainable centralized force, because they are in opposite
direction of nature's quest for maximum Entropy (max independent
inter-actors):

http://www.coolpage.com/commentary/economic/shelby/Mass-Entropy_Equivalence.html

Redistribution of individual innovation to social ignorance, is a move
towards the center of bell curve and ignorant of not-so-long-tail
distributions of generational scale.

We compete to bring the most truth (max inter-actors).

--- In json@yahoogroups.com, "Shelby Moore" <shelby@...> wrote:
> Viability of JSON's strength as unchanging specification, will depend
> on the correctness and minimal completeness of it's primitives model.
> Agree with your goal, but want to hash out the primitive "sweet spot".
>
> RFC 4627 for JSON states:
>
> "It is derived from the object literals of JavaScript, as defined in
> the ECMAScript Programming Language Standard, Third Edition [ECMA]"
>
> ECMA-262 specifies a Type and Value for Undefined, but granted it does
> not specify a literal for undefined. I.e. Undefined can be create in
> execution context, but not in literal assignment.
>
> What is not clear to me is when did the identifier, undefined, become
> an assignable global object?  Mozilla claims JavaScript 1.3 and
ECMA-262:
>
>
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Proper\
ties:undefined
>
> If true, then treating undefined as a literal in JSON, is compatible
> with ECMA-262. And my prior posts have argued no additional
> portability burden for an undefined literal (other than the legacy
> issue of current RFC 4627 grammar).

I anticipate that there will be other languages that are based on or
inspired by JSON. These will push the model in interesting directions.
But there will be always be a simple JSON because there is a benefit
in having something that is reliable and minimally adequate.

In my view, JavaScript's undefined was a mistake. There are too many
similar falsy values in the the language. Most programmers are
confused about the differences. The undefined property is
inconsistent. It indicates a missing member, but it can be the value
of present members. As a name, it is implemented as a writable global
variable, a feature with alarming security and reliability
consequences. This is not a feature to fight for. It is a mistake that
cannot be rectified.

At the time I formulated JSON, JavaScript was not a popular language,
and it was generally held in very low esteem. One of my design goals
was to hide JavaScript's defects. That is why keys must be quoted in
JSON, because I did not want to explain JavaScript's absurd reserved
word policy in the JSON spec. The undefined value was excluded for the
similar reasons.

JavaScript could use a generalized serialization format, something
that understands functions and prototypes and undefined. That language
could be derived from JSON, but JSON should never be that language
because it would violate the goal of being minimal, stable, and
independent.

Douglas Crockford wrote:
> I anticipate that there will be other languages that are based on or
> inspired by JSON. These will push the model in interesting directions.
> But there will be always be a simple JSON because there is a benefit
> in having something that is reliable and minimally adequate.

Agreed this is an exciting frontier, based on a conceptually
RISC-like, yet data complete model that is JSON. A point I grasped
probably due to your writings (your blog included) over the past year.
However, even after reading your much appreciated insight and
experience, I still think JSON is missing one crucial literal type.

> In my view, JavaScript's undefined was a mistake. There are too many
> similar falsy values in the the language.

In my view, false, null, and undefined are not all similar, and each
is a critical fundamental primitive for the semantic web. Boolean and
null Object both are referent data types. The Boolean false is
fundamental binary gate of digital logic. The null Object means
semantically we require an Object, but we don't know which object.
Requiring an Object is not the same as requiring a true/false outcome.
  Requiring an Object and getting a null outcome, is not the same as
requiring a Boolean and getting false. Those are very different semantics.

The undefined Object means we know the identifier that refers, but the
referent (to which it refers) is unspecified.  Thus, undefined is
necessary for distinguishing between unspecified data and data that
the application does not contemplate. If we use null to represent
unspecified data, then we no longer have a way to distinguish between
unspecified data (no referent) and specified data (referent) that has
no value.

If I have an application that expects a data structure with two
members, "one" and "two", then if it receives:

{ "one" : null }

then it is clear that "one" is specified as no value, but it is
ambiguous whether the received data is saying that "two" is
unspecified, or if it is saying that "two" is not even contemplated.
In the latter case, the sending application might be in error, because
it doesn't even contemplate "two" in it's output.

If { "one" : null, "two" : null } is received, then it is ambiguous
whether "one" and "two" are specified as no value, or whether they
were contemplated but are not specified.

Whereas, if { "one" : null, "two" : undefined } is received, then
there is no ambiguity.

The distinction between null and undefined becomes more noticeable,
when one gets into specifying semantics in data structures, as became
evident when I decided to use the pair names as the semantic data
types implicitly, to avoid the overhead (and reduction in human
readability) of an orthogonal schema language.  In my formulation, the
data is the schema, via inheritance.  Thus the critical need to
distinguish between optional, unspecified and required, no value in
inheritance.


> Most programmers are
> confused about the differences.

That may be true. Douglas, afaik your web site (crockford.com) has
helped clarify many things about JavaScript, perhaps my explanations
above may be helpful in this regard at some point.  I claim no
copyright nor recognition. Be it as it may.

> The undefined property is
> inconsistent. It indicates a missing member, but it can be the value
> of present members.

As I detailed above, I think it is critical to view undefined as the
type of the identifier, not of the referent. Then there is no
inconsistency, because undefined is not concerned with assignment, as
it is not a property of the referent of the identifier. You are not
asking "is the identifier not attached to a referent?", but instead
"was this identifier assigned to undefined?". Per my first post of
this thread, one can distinguish from a property identifier which was
never assigned to undefined, using the 'in' operator, but that is
orthogonal to the question that "=== undefined" asks about the identifier.

> As a name, it is implemented as a writable global
> variable, a feature with alarming security and reliability
> consequences.

Thanks for making me aware that this.undefined is a writable property
of the global this object. I did some testing in Firebug's console,
and even after undefined has been modified (e.g. this.undefined =
null;), new instances of uninitialized var or missing properties,
still get assigned to the original undefined object. So it means to be
safe against malicious code, we need to re-initialize upon any call backs:

var undefined;
this.undefined = undefined;


> This is not a feature to fight for. It is a mistake that
> cannot be rectified.

Why can't the writeable security hole be rectified?


> At the time I formulated JSON, JavaScript was not a popular language,
> and it was generally held in very low esteem. One of my design goals
> was to hide JavaScript's defects. That is why keys must be quoted in
> JSON, because I did not want to explain JavaScript's absurd reserved
> word policy in the JSON spec. The undefined value was excluded for the
> similar reasons.

I am not following you? If undefined was a literal in JSON, afaics it
would work fine in eval(), as long as this.undefined is patched up
before calling eval, just in case it was overwritten.


> JavaScript could use a generalized serialization format, something
> that understands functions and prototypes and undefined. That language
> could be derived from JSON, but JSON should never be that language
> because it would violate the goal of being minimal, stable, and
> independent.

That may be true, but that is not at all what I am here for.  I am
also working on a language agnostic, minimalistic primitive syntax. I
am merely trying to enable the minimum necessary to launch the
Semantic Web, in much simpler manner than all that RDF+XML complexity.
  I simply believe that automated code reuse is not only for science
fiction. And I believe OpenSocial, MySpace, FaceBook, etc are all
wrong and very vulnerable.

Douglas, your insightful replies are helping me to understand better
your and my concepts.  Perhaps it was Einstein who said (paraphrased)
that until one is forced to explain their concepts, they don't really
understand them well. I appreciate the sound reasoning that got JSON
to where it is today, but I remain yet unconvinced that undefined is
not a critically missing literal. I remain open-minded, and I
respectfully do not desire to drag us into a long debate.  Afaics,
there is nothing wrong with JSON remaining static, and then some
proposal for JSON+undefined for those who need it. I hope that is
harmonious.

> Douglas Crockford wrote:
> > As a name, it is implemented as a writable global
> > variable, a feature with alarming security and reliability
> > consequences.

On further thought, this is not any more a security concern, than
JavaScript (or the web page) itself. Agreed, it should be made
read-only to prevent against non-malicious untended modification.

There is no security in any JavaScript, because rogue code can change
any user code.  The entire current concept of browser security is
conceptually flawed, and the solution is as follows:

http://www.coolpage.com/commentary/economic/shelby/security.html

The only trustable web page is the one where ALL referents (resources)
come from a trusted source. Security is fundamentally trust.
Increasing granularity of trust, decreases security conflicts.  I give
a proposal using sub-frames to segregate private data from the rest of
the web page.

How about moving security-related discussion to another thread or group?

And with regards to adding keyword 'undefined' to json, I would be
strongly against adding any such language-specific keywords. As a
non-javascript-user of json I would find it a rather silly and useless
addition. Json's goals are not, as far as I understand, to be
javascript(-only) serialization format, but rather serve as a
minimalistic generalized object notation.

-+ Tatu +-

On Tue, May 27, 2008 at 3:04 AM, Shelby Moore <shelby@...> wrote:
>> Douglas Crockford wrote:
>> > As a name, it is implemented as a writable global
>> > variable, a feature with alarming security and reliability
>> > consequences.
>
> On further thought, this is not any more a security concern, than
> JavaScript (or the web page) itself. Agreed, it should be made
> read-only to prevent against non-malicious untended modification.
>
> There is no security in any JavaScript, because rogue code can change
> any user code.  The entire current concept of browser security is
> conceptually flawed, and the solution is as follows:
>
> http://www.coolpage.com/commentary/economic/shelby/security.html
>
> The only trustable web page is the one where ALL referents (resources)
> come from a trusted source. Security is fundamentally trust.
> Increasing granularity of trust, decreases security conflicts.  I give
> a proposal using sub-frames to segregate private data from the rest of
> the web page.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

I've been following this particular thread with some interest --

Most modern programming languages HAVE defined "undefined" --
Undefined is NOT 0 and NOT 1, and NOT 'null' AND NOT 'not null', and
NOT true and NOT false... Bottom line: undefined is actually defined
as something that is NOT DEFINED...

As far as JSON goes -- by definition: it is "JavaScript Object
Notation" -- so -- on the technical definition -- JSON is in fact a
"JavaScript-ONLY" object notation mechanism. The great thing about
JSON is that it is pretty much generalized -- there are
implementations in a ton of different languages.

I have thought for a long time that there probably ought to be a
strict "generalized object-notation" group [GONF ? Generalized Object
Notation Format ???].

An underlying issue with JSON is the name itself -- because JSON is
so versatile, has support in a multitude of languages, and 100%
flexible [I use it for many things including: server-server
communication in lieu of serialized objects, client-server
communication, browser-server [Web 2.x]] --

I use JSON everywhere: even when not using a JavaScript client or web
browser -- that is the beauty of it...

Maybe it is time to think about how big JSON really is and how
completely useful it is as a high-speed data transfer mechanism and
re-consider the name -- it ain't just plain ol' JavaScript anymore...
It REALLY IS a multi-purpose, multi-platform data interchange and
transmission format. Maybe it shuld be called something more
appropriate to it's function.





--- In json@yahoogroups.com, "Tatu Saloranta" <tsaloranta@...> wrote:
>
> How about moving security-related discussion to another thread or
group?
>
> And with regards to adding keyword 'undefined' to json, I would be
> strongly against adding any such language-specific keywords. As a
> non-javascript-user of json I would find it a rather silly and
useless
> addition. Json's goals are not, as far as I understand, to be
> javascript(-only) serialization format, but rather serve as a
> minimalistic generalized object notation.
>
> -+ Tatu +-
>
> On Tue, May 27, 2008 at 3:04 AM, Shelby Moore <shelby@...> wrote:
> >> Douglas Crockford wrote:
> >> > As a name, it is implemented as a writable global
> >> > variable, a feature with alarming security and reliability
> >> > consequences.
> >
> > On further thought, this is not any more a security concern, than
> > JavaScript (or the web page) itself. Agreed, it should be made
> > read-only to prevent against non-malicious untended modification.
> >
> > There is no security in any JavaScript, because rogue code can
change
> > any user code.  The entire current concept of browser security is
> > conceptually flawed, and the solution is as follows:
> >
> > http://www.coolpage.com/commentary/economic/shelby/security.html
> >
> > The only trustable web page is the one where ALL referents
(resources)
> > come from a trusted source. Security is fundamentally trust.
> > Increasing granularity of trust, decreases security conflicts.  I
give
> > a proposal using sub-frames to segregate private data from the
rest of
> > the web page.
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>

I agree with this totally.   And frankly I am finding the
current discussion a bit boring and a waste of time.

Best,
Mark
P6R, Inc


On Tue, 27 May 2008 09:46:23 -0700
   "Tatu Saloranta" <tsaloranta@...> wrote:
> How about moving security-related discussion to another
>thread or group?
>
> And with regards to adding keyword 'undefined' to json,
>I would be
> strongly against adding any such language-specific
>keywords. As a
> non-javascript-user of json I would find it a rather
>silly and useless
> addition. Json's goals are not, as far as I understand,
>to be
> javascript(-only) serialization format, but rather serve
>as a
> minimalistic generalized object notation.
>
> -+ Tatu +-
>
> On Tue, May 27, 2008 at 3:04 AM, Shelby Moore
><shelby@...> wrote:
>>> Douglas Crockford wrote:
>>> > As a name, it is implemented as a writable global
>>> > variable, a feature with alarming security and
>>>reliability
>>> > consequences.
>>
>> On further thought, this is not any more a security
>>concern, than
>> JavaScript (or the web page) itself. Agreed, it should
>>be made
>> read-only to prevent against non-malicious untended
>>modification.
>>
>> There is no security in any JavaScript, because rogue
>>code can change
>> any user code.  The entire current concept of browser
>>security is
>> conceptually flawed, and the solution is as follows:
>>
>> http://www.coolpage.com/commentary/economic/shelby/security.html
>>
>> The only trustable web page is the one where ALL
>>referents (resources)
>> come from a trusted source. Security is fundamentally
>>trust.
>> Increasing granularity of trust, decreases security
>>conflicts.  I give
>> a proposal using sub-frames to segregate private data
>>from the rest of
>> the web page.
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>

-------------------------
Mark Joseph, Ph.D.
President and Secretary
P6R, Inc.
http://www.p6r.com
408-205-0361
Fax: 831-476-7490
Skype: markjoseph_sc
IM: (Yahoo) mjoseph8888
      (AIM) mjoseph8888

Agree++.

Shelby, when you've got a next-generation semantic web 3.0 mashup demo
that desperately needs "undefined", we'll be able to see whether it's
a useful concept. Until then, I agree with Douglas that it's a waste
of energy to pull it in to JSON.

FWIW, I can see how the decision to include "javascript" in the JSON
name is leading to a mountain of confusion, but I've always seen the
format as a way to interop between a variety of languages and
platforms. "Undefined" would really muddy those waters.

-mike.

On May 27, 2008, at 10:30 AM, Mark Joseph wrote:

> I agree with this totally. And frankly I am finding the
> current discussion a bit boring and a waste of time.
>
> Best,
> Mark
> P6R, Inc
>
> On Tue, 27 May 2008 09:46:23 -0700
> "Tatu Saloranta" <tsaloranta@...> wrote:
> > How about moving security-related discussion to another
> >thread or group?
> >
> > And with regards to adding keyword 'undefined' to json,
> >I would be
> > strongly against adding any such language-specific
> >keywords. As a
> > non-javascript-user of json I would find it a rather
> >silly and useless
> > addition. Json's goals are not, as far as I understand,
> >to be
> > javascript(-only) serialization format, but rather serve
> >as a
> > minimalistic generalized object notation.
> >
> > -+ Tatu +-
> >
> > On Tue, May 27, 2008 at 3:04 AM, Shelby Moore
> ><shelby@...> wrote:
> >>> Douglas Crockford wrote:
> >>> > As a name, it is implemented as a writable global
> >>> > variable, a feature with alarming security and
> >>>reliability
> >>> > consequences.
> >>
> >> On further thought, this is not any more a security
> >>concern, than
> >> JavaScript (or the web page) itself. Agreed, it should
> >>be made
> >> read-only to prevent against non-malicious untended
> >>modification.
> >>
> >> There is no security in any JavaScript, because rogue
> >>code can change
> >> any user code. The entire current concept of browser
> >>security is
> >> conceptually flawed, and the solution is as follows:
> >>
> >> http://www.coolpage.com/commentary/economic/shelby/security.html
> >>
> >> The only trustable web page is the one where ALL
> >>referents (resources)
> >> come from a trusted source. Security is fundamentally
> >>trust.
> >> Increasing granularity of trust, decreases security
> >>conflicts. I give
> >> a proposal using sub-frames to segregate private data
> >>from the rest of
> >> the web page.
> >>
> >>
> >> ------------------------------------
> >>
> >> Yahoo! Groups Links
> >>
> >>
> >>
> >>
>
> -------------------------
> Mark Joseph, Ph.D.
> President and Secretary
> P6R, Inc.
> http://www.p6r.com
> 408-205-0361
> Fax: 831-476-7490
> Skype: markjoseph_sc
> IM: (Yahoo) mjoseph8888
> (AIM) mjoseph8888
>
>

----------------------------------------------------------------
michal migurski- mike@...
                   415.558.1610





[Non-text portions of this message have been removed]

Hi Greg,

GP> As far as JSON goes -- by definition: it is "JavaScript Object
GP> Notation" -- so -- on the technical definition -- JSON is in fact a
GP> "JavaScript-ONLY" object notation mechanism.

I've never interpreted it that way. I always took the JS part to mean
that JSON's syntax was based on JavaScript's syntax, which gives you
context (and a nice acronym :). From what I've read, JSON is meant to
be language independent. If they change the JS/ECMA standard to
something that doesn't support that goal, JSON won't work well with
its namesake.

On undefined, I don't think JSON needs it, even if some languages have
it. In my language of choice, as with some others, dealing with
undefined can make for more work, and not much more value (IMO). If
it's undefined, why is it there? Not to say it's never useful, but it
doesn't seem crucial in an object notation like JSON.

Ironically, it would probably be easier for me to add undefined/unset
support to the JSON module for REBOL (my language of choice) than it
is to support strings as keys in objects (which it can't, really).

--Gregg

Greg Patnude scripsit:

> Most modern programming languages HAVE defined "undefined" --
> Undefined is NOT 0 and NOT 1, and NOT 'null' AND NOT 'not null', and
> NOT true and NOT false... Bottom line: undefined is actually defined
> as something that is NOT DEFINED...

"Not code. Not name. Not mind. Not things. Always changing, yet never changing."

> As far as JSON goes -- by definition: it is "JavaScript Object
> Notation" -- so -- on the technical definition -- JSON is in fact a
> "JavaScript-ONLY" object notation mechanism.

         A cocky novice once said to Stallman: "I can guess why the editor
         is called Emacs, but why is the justifier called Bolio?" Stallman
         replied forcefully, "Names are but names. 'Emack & Bolio's' is the
         name of a popular ice cream shop in Boston-town. Neither of these men
         had anything to do with the software."

         His question answered, yet unanswered, the novice turned to go,
         but Stallman called to him: "Neither Emack nor Bolio had anything
         to do with the ice cream shop, either."

This koan is called the "ice cream koan".

--
John Cowan  cowan@...  http://www.ccil.org/~cowan
Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory
that the mongoose first came to India on a raft from Polynesia.
         --blurb for Rikki-Kon-Tiki-Tavi

On Tue, May 27, 2008 at 10:19 AM, Greg Patnude <gpatnude@...> wrote:
...
> Most modern programming languages HAVE defined "undefined" --
> Undefined is NOT 0 and NOT 1, and NOT 'null' AND NOT 'not null', and
> NOT true and NOT false... Bottom line: undefined is actually defined
> as something that is NOT DEFINED...

I don't think it's true for most (modern) programming languages;
although it may be true for most _scripting_ languages. This is
different from, say, null, which has a counterpart in about any
language including c and c++ (unlike someone claimed earlier).

> As far as JSON goes -- by definition: it is "JavaScript Object
> Notation" -- so -- on the technical definition -- JSON is in fact a
> "JavaScript-ONLY" object notation mechanism. The great thing about

Not really: you can not derive semantics from etymology. Names are
just names and like you mention, they can lead to intuitive yet
incorrect guesses.

To understand goals, one could consult the author... and Doug has
already pointed out his view on the matter.

Additionally reading the JSON RFC, http://www.ietf.org/rfc/rfc4627.txt
one can find:

"JavaScript Object Notation (JSON) is a lightweight, text-based,
    language-independent data interchange format"

Nowhere does it say anything about coupling with Javascript.
My understanding is that just JS syntax was used. In a funny way makes
sense: JavaScript has little to do with Java, beyond syntax; and
similarly JSON just took syntax from Javascript (or, from Java, if you
will).

Apologies for prolonging this flogging of a dead horse,

-+ Tatu +-

Thanks to all that replied to my prior post.  This is my reply to you all.

1) Undefined is essential in languages that treat identifiers as hash
keys of an object (i.e. modern dynamic scripting languages). Static
identifier languages, can simulate dynamic identifiers with a hash
collection class.

2) Afair, K&R (ANSI) C did not have null, only void*. In K&R (ANSI) C,
void is not valid in a conditional nor assignment expression, and
identifiers are not dynamically constructed and typed.

3) Undefined is a critical primitive in any hash object data
structure, that supports inheritance. I already explained my logic in
prior post.

This will all become more obvious to you all, as someone actually
brings real world application of Semantic Web to reality.

4) I agree with Douglas not to modify the JSON standard specification,
but rather to usurp it (JSON+ or whatever it may be called) if the
market shall be so. I believe in de facto (competing) standards, not
in centrally managed ones, which is one of the main motivations of the
development I am working on. I believe in a million points of light
competing. I believe in freedom and liberty.

Okay enough talk from me. Your comments have encouraged me. Thanks
very much to all. And best wishes to all as well.

Mark thinks it's boring... we should all move on.


----- Original Message ----
From: Mark Joseph <mark@...>
To: json@yahoogroups.com
Sent: Tuesday, May 27, 2008 11:30:20 AM
Subject: Re: [json] Re: JSON syntax grammar is missing 'undefined' literal value


I agree with this totally.   And frankly I am finding the
current discussion a bit boring and a waste of time.

Best,
Mark
P6R, Inc

On Tue, 27 May 2008 09:46:23 -0700
"Tatu Saloranta" <tsaloranta@gmail. com> wrote:
> How about moving security-related discussion to another
>thread or group?
>
> And with regards to adding keyword 'undefined' to json,
>I would be
> strongly against adding any such language-specific
>keywords. As a
> non-javascript- user of json I would find it a rather
>silly and useless
> addition. Json's goals are not, as far as I understand,
>to be
> javascript(- only) serialization format, but rather serve
>as a
> minimalistic generalized object notation.
>
> -+ Tatu +-
>
> On Tue, May 27, 2008 at 3:04 AM, Shelby Moore
><shelby@coolpage. com> wrote:
>>> Douglas Crockford wrote:
>>> > As a name, it is implemented as a writable global
>>> > variable, a feature with alarming security and
>>>reliability
>>> > consequences.
>>
>> On further thought, this is not any more a security
>>concern, than
>> JavaScript (or the web page) itself. Agreed, it should
>>be made
>> read-only to prevent against non-malicious untended
>>modification.
>>
>> There is no security in any JavaScript, because rogue
>>code can change
>> any user code.  The entire current concept of browser
>>security is
>> conceptually flawed, and the solution is as follows:
>>
>> http://www.coolpage .com/commentary/ economic/ shelby/security. html
>>
>> The only trustable web page is the one where ALL
>>referents (resources)
>> come from a trusted source. Security is fundamentally
>>trust.
>> Increasing granularity of trust, decreases security
>>conflicts.  I give
>> a proposal using sub-frames to segregate private data
>>from the rest of
>> the web page.
>>
>>
>> ------------ --------- --------- ------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>

------------ --------- ----
Mark Joseph, Ph.D.
President and Secretary
P6R, Inc.
http://www.p6r. com
408-205-0361
Fax: 831-476-7490
Skype: markjoseph_sc
IM: (Yahoo) mjoseph8888
(AIM) mjoseph8888





[Non-text portions of this message have been removed]