Please check out my new C++ JSON interface library at:

http://cajun-jsonapi.sourceforge.net/

What makes it better than the others already available? A major goal
of the library was a powerful interface but a short learning curve.
The C++ Standard Template Library served as an inspiration for the
interface, and so should be immediately intuitive to anyone familiar
with the language. See the release notes for lots more information:

http://sourceforge.net/project/shownotes.php?
group_id=251569&release_id=658013


Cheers,
Terry

Does this interface allow the JSON data to be streamed in?

Thanks,
Mark
P6R, Inc


On Tue, 03 Feb 2009 12:26:31 -0000
   "terry_caton" <lc840c@...> wrote:
> Please check out my new C++ JSON interface library at:
>
> http://cajun-jsonapi.sourceforge.net/
>
> What makes it better than the others already available?
>A major goal
> of the library was a powerful interface but a short
>learning curve.
> The C++ Standard Template Library served as an
>inspiration for the
> interface, and so should be immediately intuitive to
>anyone familiar
> with the language. See the release notes for lots more
>information:
>
> http://sourceforge.net/project/shownotes.php?
> group_id=251569&release_id=658013
>
>
> Cheers,
> Terry
>
>

-------------------------
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

JSON.simple introduces a simplified and stoppable SAX-like content handler to
process JSON text stream. Please take a look if you are interested in it:

http://code.google.com/p/json-simple/wiki/DecodingExamples#Example_5_-_Stoppable\
_SAX-like_content_handler


--
JSON: Action in AJAX!

JSON - http://www.json.org
JSON.simple - http://code.google.com/p/json-simple/


       ___________________________________________________________
   好玩贺卡等你发，邮箱贺卡全新上线！
http://card.mail.cn.yahoo.com/

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the json
group.

   File        : /json-lib-1_0_2.zip
   Uploaded by : shawnsilverman <shawn@...>
   Description : A Java library for processing JSON data.

You can access this file at the URL:
http://groups.yahoo.com/group/json/files/json-lib-1_0_2.zip

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

shawnsilverman <shawn@...>

--- In json@yahoogroups.com, "Mark Joseph" <mark@...> wrote:
>
> Does this interface allow the JSON data to be streamed in?
>

Yes it does. In fact, the library's built-in
input/output capability is based on the standard
istream & ostream classes, so any C++ stream-based
file/network/console interface should work automagically.
Furthermore, this stream-based serialization is
implemented "externally" via the visitor pattern,
which facilitates the straighforward implementation of
additional operations (graph rendering, document
validation, custom network streaming, etc).

On Tue, Feb 3, 2009 at 8:09 PM, Fang Yidong <fangyidong@...> wrote:
> JSON.simple introduces a simplified and stoppable SAX-like content handler to
process JSON text stream. Please take a look if you are interested in it:
>

If you are interested in application code controlling parsing, why not
just use Stax(-like) pull interface? Code example given would be quite
a bit simpler with "pull" approach; essentially little more than
recursive descent, or with some interfaces, linear iteration like:

---
JsonParser jp = factory.createJsonParser(input);
JsonToken t;

while ((t = jp.nextToken()) != null) {
   if (t == JsonToken.FIELD_NAME && "id".equals(t.getCurrentName())) {
     break;
   }
}
if (t != null) { // get value for the field
   t = jp.nextToken();
   System.out.println("found id, value: "+jp.getText());
}
---

And you could obviously built simpler abstractions for matching on top of this.

The main benefit of push-interface like SAX is that it is easier to
pipeline multiple processing stages. Otherwise it is rather cumbersome
and inconvenient way to process data that naturally comes in
well-defined and structured order.

I am asking because oftentimes xml/json/whatever parser writers use
SAX-like approaches without knowing that it's only way to slice and
dice data, and often not the best.

-+ Tatu +-

Well, if I am right, the parser in your example is essentially a lexer, with
slightly higher abstraction.

It's true that it's convenient to control in simple case. But in a slightly more
complex scenario, such as retrieving data in some desired location (for example,
'/store/book[1]/title' in XPath expression), I don't think the code using a
SAX(-like) parser is much more complex than using a StAX(-like) parser.

Besides easier to pipeline, a SAX(-like) parser requires smaller memory
footprint and is faster, and the stoppable SAX-like interface introduced by
JSON.simple avoids the drawback that a traditional SAX parser requires the
entire document to be parsed to get a simple data.

I think different applications require different abstraction levels.
JSON.simple's stoppable SAX-like interface provides a new option to the user.
It's your choice of adopting it or not.
鍙戜欢浜�: Tatu Saloranta <tsaloranta@...>
涓婚: Re: [json] Stoppable SAX-like interface for streaming input of JSON 
text
鏀朵欢浜�: json@yahoogroups.com
鏃ユ湡: 2009,25,鍛ㄥ洓,1:22涓婂崍











             On Tue, Feb 3, 2009 at 8:09 PM, Fang Yidong <fangyidong@yahoo.
com.cn> wrote:

> JSON.simple introduces a simplified and stoppable SAX-like content handler to
process JSON text stream. Please take a look if you are interested in it:

>



If you are interested in application code controlling parsing, why not

just use Stax(-like) pull interface? Code example given would be quite

a bit simpler with "pull" approach; essentially little more than

recursive descent, or with some interfaces, linear iteration like:



---

JsonParser jp = factory.createJsonP arser(input) ;

JsonToken t;



while ((t = jp.nextToken( )) != null) {

   if (t == JsonToken.FIELD_ NAME && "id".equals( t.getCurrentName ())) {

     break;

   }

}

if (t != null) { // get value for the field

   t = jp.nextToken( );

   System.out.println( "found id, value: "+jp.getText( ));

}

---



And you could obviously built simpler abstractions for matching on top of this.



The main benefit of push-interface like SAX is that it is easier to

pipeline multiple processing stages. Otherwise it is rather cumbersome

and inconvenient way to process data that naturally comes in

well-defined and structured order.



I am asking because oftentimes xml/json/whatever parser writers use

SAX-like approaches without knowing that it's only way to slice and

dice data, and often not the best.



-+ Tatu +-

























       ___________________________________________________________
   濂界帺璐哄崱绛変綘鍙戯紝閭璐哄崱鍏ㄦ柊涓婄嚎锛�
http://card.mail.cn.yahoo.com/

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

On Wed, Feb 4, 2009 at 11:28 PM, Fang Yidong <fangyidong@...> wrote:
> Well, if I am right, the parser in your example is essentially a lexer, with
slightly higher abstraction.

Not really. You may want to read a bit on Stax API for Java: I assume
you are familiar with SAX API.
Both operate at roughly same level of abstraction, and handle parser
tasks of ensuring proper structure of the data format regarding
nesting (ordering of parsed tokens).

> It's true that it's convenient to control in simple case. But in a slightly
more complex scenario, such as retrieving data in some desired location (for
example,
> '/store/book[1]/title' in XPath expression), I don't think the code using a
SAX(-like) parser is much more complex than using a StAX(-like) parser.

That is debatable (I think event-handling approach is inherently less
intuitive personally, others disagree).
Path expressions can obviously run on either push or pull mode, so I
would agree in that convenience factor is not as big as when comparing
to higher abstractions (tree model, data binding).

But I was just pointing out that the example does not show much benefits.
So it would be good to showcase something where it does actually help?

Or perhaps it's just that json.simple exposes push interface and this
is an incremental improvement to the current way of doing this?

> Besides easier to pipeline, a SAX(-like) parser requires smaller memory
> footprint and is faster, and the stoppable SAX-like interface introduced by

No and no. Why would this be the case? Both are streaming, need to
keep limited amount of state. These are not true for xml pull vs push
parsers, and I haven't observed this with json parsers either
(including cases where a single parsers exposes both types of
interfaces).
My experience has been that in this regard approaches are roughly
equivalent, differences are between parsers, not between APIs.

> JSON.simple avoids the drawback that a traditional SAX parser requires the
> entire document to be parsed to get a simple data.

Right. That is a potentially useful incremental improvement. The
example pointed to made it sound like there were other benefits, or
that it was an optimal way of handling the task.
For what it's worth, push interface could be used to build a simple
solution too, just stop on match, don't worry about nesting etc. Or,
pull alternative changed to handle additional constraints.

> I think different applications require different abstraction levels.
JSON.simple's

But there is no different abstraction level here. Push (SAX) and pull
streaming interfaces work at same level of abstraction. Higher levels
would be tree models and data binding, both of which can be
implemented on top of either of these lower level approaches.

> stoppable SAX-like interface provides a new option to the user.
> It's your choice of adopting it or not.

Sure. But as part of advocating that, isn't it good to show why would
it make sense to use it?

As to stoppability of push parsing, the usual method so far has been
to throw an exception from the event handler. Would that not have
worked?

-+ Tatu +-

On Wed, Feb 4, 2009 at 11:28 PM, Fang Yidong <fangyidong@yahoo.
com.cn> wrote:

> > Well, if I am right, the parser in your example is essentially a lexer, with
slightly higher abstraction.



> Not really. You may want to read a bit on Stax API for Java: I assume

> you are familiar with SAX API.

> Both operate at roughly same level of abstraction, and handle parser

> tasks of ensuring proper structure of the data format regarding

> nesting (ordering of parsed tokens).


I did go through JSR 173 before comparing. I mean, the StAX parser in your
example is similar to a lexer such as org.json.simple.parser.Yylex:

Yylex lexer = new Yylex(in);
Yytoken token;
while((token = lexer.yylex()) != null){
   ...
}

But your StAX parser keeps the states so that the user is able to check if the
current token is a field name, while the lexer does not. So I said it's a higher
abstraction (over a lexer). But except the field name, other tokens (start/end
of a object, start/end of an array) are similar to ones that a lexer return.

Although it's quite low level, I agree it's good to standardize it and StAX has
its advantages in some applications.

> > It's true that it's convenient to control in simple case. But in a slightly
more complex scenario, such as retrieving data in some desired location (for
example,

> > '/store/book[ 1]/title' in XPath expression), I don't think the code using a
SAX(-like) parser is much more complex than using a StAX(-like) parser.



> That is debatable (I think event-handling approach is inherently less

> intuitive personally, others disagree).

> Path expressions can obviously run on either push or pull mode, so I

> would agree in that convenience factor is not as big as when comparing

> to higher abstractions (tree model, data binding).



> But I was just pointing out that the example does not show much benefits.

> So it would be good to showcase something where it does actually help?



> Or perhaps it's just that json.simple exposes push interface and this

> is an incremental improvement to the current way of doing this?



> Besides easier to pipeline, a SAX(-like) parser requires smaller memory

> footprint and is faster, and the stoppable SAX-like interface introduced by



> No and no. Why would this be the case? Both are streaming, need to

> keep limited amount of state. These are not true for xml pull vs push

> parsers, and I haven't observed this with json parsers either

> (including cases where a single parsers exposes both types of

> interfaces).

> My experience has been that in this regard approaches are roughly

> equivalent, differences are between parsers, not between APIs.

I agree. I was using the data from JSON.simple's implementation to compare with
a StAX parser.

> JSON.simple avoids the drawback that a traditional SAX parser requires the

> entire document to be parsed to get a simple data.



> Right. That is a potentially useful incremental improvement. The

> example pointed to made it sound like there were other benefits, or

> that it was an optimal way of handling the task.

> For what it's worth, push interface could be used to build a simple

> solution too, just stop on match, don't worry about nesting etc. Or,

> pull alternative changed to handle additional constraints.



> > I think different applications require different abstraction levels.
JSON.simple' s



> But there is no different abstraction level here. Push (SAX) and pull

> streaming interfaces work at same level of abstraction. Higher levels

> would be tree models and data binding, both of which can be

> implemented on top of either of these lower level approaches.

I mean users may choose among DOM-like, SAX-like and StAX-like parsers.


> > stoppable SAX-like interface provides a new option to the user.

> > It's your choice of adopting it or not.



> Sure. But as part of advocating that, isn't it good to show why would

> it make sense to use it?



> As to stoppability of push parsing, the usual method so far has been

> to throw an exception from the event handler. Would that not have

> worked?

Not really. Here stoppable also means it's resumable. That is, the user can
pause at a point, doing other works, and then resume parsing or stop. Please
refer the example for detail:

http://code.google.com/p/json-simple/wiki/DecodingExamples#Example_5_-_Stoppable\
_SAX-like_content_handler

Actually, JSR 173(jsr173_07.pdf) argues it has advantages over SAX because:

One drawback to the SAX API is that the programmer must keep track of the
current
state of the document in the code each time they process an XML document and
thus cannot
iteratively process it. Another drawback to SAX is that the entire document
needs to be
parsed at one time.

The first drawback is partly true but in complex scenarios, a user with StAX
parser may also need to keep track of states such as nesting levels,
parent-child relationships and so on.

The purpose of JSON.simple's stoppable SAX-like interface is to help relieve
such issues.

Yidong Fang


       ___________________________________________________________
   好玩贺卡等你发，邮箱贺卡全新上线！
http://card.mail.cn.yahoo.com/

On Thu, Feb 5, 2009 at 4:52 PM, Fang Yidong <fangyidong@...> wrote:
>
>            On Wed, Feb 4, 2009 at 11:28 PM, Fang Yidong <fangyidong@yahoo.
com.cn> wrote:
>
>> > Well, if I am right, the parser in your example is essentially a lexer,
with slightly higher abstraction.

>> Not really. You may want to read a bit on Stax API for Java: I assume
>
> I did go through JSR 173 before comparing. I mean, the StAX parser in your
example is similar to a lexer such as org.json.simple.parser.Yylex:

Ah ok. Maybe I misread your comment: if you meant it's lower level of
abstraction than a tree model, yes.
I meant to say that SAX(-like) API is at similar level of abstraction
as Stax(-like).
...
> I mean users may choose among DOM-like, SAX-like and StAX-like parsers.

Ok yes, that makes sense.

(although DOM is technically not a parser but a tree model built on
top of that, but many users still call it a parser)

>> > stoppable SAX-like interface provides a new option to the user.
>
>> As to stoppability of push parsing, the usual method so far has been
>> to throw an exception from the event handler. Would that not have
>> worked?
>
> Not really. Here stoppable also means it's resumable. That is, the user can
pause at a point, doing other works, and then resume parsing or stop. Please
refer the example for detail:

Ok. That makes more sense then, thank you for pointing this out.

...
> Actually, JSR 173(jsr173_07.pdf) argues it has advantages over SAX because:
>
> One drawback to the SAX API is that the programmer must keep track of the
...
> iteratively process it. Another drawback to SAX is that the entire document
needs to be
> parsed at one time.
>
> The first drawback is partly true but in complex scenarios, a user with StAX
parser
> may also need to keep track of states such as nesting levels, parent-child
> relationships and so on.

Maybe, but not necessarily, because this information if implicit
within call stack (except for having to track end markers).
That is, it's a recursive-descent kind of approach where you know
where you came from, usually without additional tracking of location.
Code branches based on constructs encountered.

> The purpose of JSON.simple's stoppable SAX-like interface is to help relieve
such
> issues.

Ok.

-+ Tatu +-

For those who might be interested, I have started new a Google
group/mailing list for the continued development of a language/syntax
for JSON querying:
http://groups.google.com/group/json-query

This group's purpose is to discuss, evolve, and create a specification
for JSON querying, building on existing designs to provide robust
comprehensive language for searching and retrieving information from
JSON-style object-oriented data structures.

The goals for the JSON Query language can be found at:
http://groups.google.com/group/json-query/web/json-query-requirements
and are listed below:

     * Build on JSONPath <http://goessner.net/articles/JsonPath/> - The
       most popular existing format for retrieving data from JSON
       structures is JSONPath. JSONPath has numerous implementations, and
       we wish to build on these.
     * Progressive operator evaluation -
           o Queries can be evaluated by left-to-right execution of
             operators, reducing the complexity of implementations.
           o The query language can be used a query format with URIs for
             RESTful querying of data. It should be possible to postpend
             a query to a URI to indicate a query into the data/resource
             referred by the URI.
           o The query syntax should be suitable as query component in
             the URI and provide alternate to
             application/x-www-form-urlencoded for encoding more complex
             queries. The query format could potentially be a MIME type
             application/jsonquery.
     * Maximize similarity with JavaScript/C-style syntax - JSON itself
       is a subset of JavaScript, and a JSON querying language should
       retain maximum interoperability with the language itself, with
       constructs that could potentially be included in future ECMAScript
       editions.
     * Language independence - The query language should have the
       semantics regardless of the underlying platform or framework.
     * Safely executable - It should be possible to evaluate queries from
       untrusted sources without undue risk of exposing oneself to
       security hazards.
     * Comprehensive querying capabilities:
           o Filter collections
           o Sorting results
           o Expressions with the ability to use object properties, array
             indexes, basic comparison operators, boolean operators, and
             finding matches within arrays.
           o Aggregate/group data and process it with collection
             reduction operations such as sum, maximum, minimum
           o Recursive search
           o Full text search
           o Create results of distinct sets, eliminating duplicates


     Current and Proposed Efforts

Efforts have been made to create a query language that meet the
requirements of this group with JSONQuery
<http://www.sitepen.com/blog/2008/07/16/jsonquery-data-querying-beyond-jsonpath/\
>,
which has been implemented in Dojo
<http://dojotoolkit.org/forum/dojox-dojox/dojox-grid-support/json-query>,
Persevere <http://docs.persvr.org/documentation/jsonquery>, and a
standalone JavaScript version
<http://github.com/JasonSmith/jsonquery/tree/master>. Other efforts
include Jaql <http://www.jaql.org/release/0.1/jaql-overview.html>, but
this does not meet the requirements of the specification. The current
JSONQuery syntax meets the majority of these goals but there are still
additional constructs that are needed for more comprehensive querying
capabilities. Missing capabilities include array matching, aggregation,
full text search, and distinct sets.


Thanks,
Kris


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

Hi Kris! I think this is a good group to have. :)

One quick question: I was wondering about naming of the effort.

To me, "Path" and "Query" imply somewhat different (but overlapping)
feature sets:

* Path leaning towards traversal and selection of nodes, similar to
XPath, JsonPath
* Query seems more oriented towards aggregate operations (SQL, XQuery, Jaql)

Others may have different connotations with these terms.

But given the description of goals, it seems to me that the effort
would be more geared for defining a Path language, and not Query
language.

Am I totally off here? I just wonder if naming might lead people to
read too much into the effort; even if actual goals are clearly
listed.

-+ Tatu +-

> > The first drawback is partly true but in complex scenarios, a user with StAX
parser

> > may also need to keep track of states such as nesting levels, parent-child

> > relationships and so on.


> Maybe, but not necessarily, because this information if implicit

> within call stack (except for having to track end markers).

> That is, it's a recursive-descent kind of approach where you know

> where you came from, usually without additional tracking of location.

> Code branches based on constructs encountered.


Yes, it's convenient. But I think it may result in a call stack based processor
instead of a heap based one, right? The former will cause stack overflow issues
in a deep nesting level. Here's a heap based processor for building object graph
with SAX-like interface:

http://code.google.com/p/json-simple/wiki/DecodingExamples#Example_6_-_Build_who\
le_object_graph_on_top_of_SAX-like_content



       ___________________________________________________________
   好玩贺卡等你发，邮箱贺卡全新上线！
http://card.mail.cn.yahoo.com/

I was reading over the StAX specification and BEA provides
licenses to the API, but that license prevents
sublicenses.  This means I as a vendor cannot provide my
own implementation and license that to customers.   So if
I am reading that right what is the point of that
standard?
We at P6R provide JSON and XML tools (amoung others), but
if the standard has restrictions on it then its not a real
standard that we can use.

Mark
P6R, Inc


On Thu, 5 Feb 2009 15:28:41 +0800 (CST)
   Fang Yidong <fangyidong@...> wrote:
> Well, if I am right, the parser in your example is
>essentially a lexer, with slightly higher abstraction.
>
> It's true that it's convenient to control in simple
>case. But in a slightly more complex scenario, such as
>retrieving data in some desired location (for example,
>'/store/book[1]/title' in XPath expression), I don't
>think the code using a SAX(-like) parser is much more
>complex than using a StAX(-like) parser.
>
> Besides easier to pipeline, a SAX(-like) parser requires
>smaller memory footprint and is faster, and the stoppable
>SAX-like interface introduced by JSON.simple avoids the
>drawback that a traditional SAX parser requires the
>entire document to be parsed to get a simple data.
>
> I think different applications require different
>abstraction levels. JSON.simple's stoppable SAX-like
>interface provides a new option to the user. It's your
>choice of adopting it or not.
> 鍙戜欢浜�: Tatu Saloranta <tsaloranta@...>
> 涓婚: Re: [json] Stoppable SAX-like interface for
>streaming input of JSON  text
> 鏀朵欢浜�: json@yahoogroups.com
> 鏃ユ湡: 2009,25,鍛ㄥ洓,1:22涓婂崍
>
>
>
>
>
>
>
>
>
>
>
>            On Tue, Feb 3, 2009 at 8:09 PM, Fang Yidong
><fangyidong@yahoo. com.cn> wrote:
>
>> JSON.simple introduces a simplified and stoppable
>>SAX-like content handler to process JSON text stream.
>>Please take a look if you are interested in it:
>
>>
>
>
>
> If you are interested in application code controlling
>parsing, why not
>
> just use Stax(-like) pull interface? Code example given
>would be quite
>
> a bit simpler with "pull" approach; essentially little
>more than
>
> recursive descent, or with some interfaces, linear
>iteration like:
>
>
>
> ---
>
> JsonParser jp = factory.createJsonP arser(input) ;
>
> JsonToken t;
>
>
>
> while ((t = jp.nextToken( )) != null) {
>
>  if (t == JsonToken.FIELD_ NAME && "id".equals(
>t.getCurrentName ())) {
>
>    break;
>
>  }
>
> }
>
> if (t != null) { // get value for the field
>
>  t = jp.nextToken( );
>
>  System.out.println( "found id, value: "+jp.getText( ));
>
> }
>
> ---
>
>
>
> And you could obviously built simpler abstractions for
>matching on top of this.
>
>
>
> The main benefit of push-interface like SAX is that it
>is easier to
>
> pipeline multiple processing stages. Otherwise it is
>rather cumbersome
>
> and inconvenient way to process data that naturally
>comes in
>
> well-defined and structured order.
>
>
>
> I am asking because oftentimes xml/json/whatever parser
>writers use
>
> SAX-like approaches without knowing that it's only way
>to slice and
>
> dice data, and often not the best.
>
>
>
> -+ Tatu +-
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>      ___________________________________________________________
>  濂界帺璐哄崱绛変綘鍙戯紝閭璐哄崱鍏ㄦ柊涓婄嚎锛�
> http://card.mail.cn.yahoo.com/
>
> [Non-text portions of this message have been removed]
>

-------------------------
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, Feb 7, 2009 at 4:25 PM, Mark Joseph <mark@...> wrote:
> I was reading over the StAX specification and BEA provides
> licenses to the API, but that license prevents
> sublicenses.  This means I as a vendor cannot provide my
> own implementation and license that to customers.   So if

I don't see why you would need a license to implement an API.
Generally licensing governs usage of API itself, distributing it, modifying etc.
None of those are usually needed, because Stax is part of JDK 1.6.
Or you point users to download API jar itself from whoever can provide it.

Also: whatever stax specs download bundle claims is probably incorrect.

But yes, clearly BEA screwed up licensing mentions and other parts.

> I am reading that right what is the point of that
> standard?
> We at P6R provide JSON and XML tools (amoung others), but
> if the standard has restrictions on it then its not a real
> standard that we can use.

Just to be clear: Stax API itself has little to do with Json. It is a
Java xml processing API, and would be of little help for Json. There's
no point in trying to implement it, due to fundamental differences
between xml and json data formats.

But similar style ("pull parsing") is useful.

-+ Tatu +-

On Fri, Feb 6, 2009 at 5:33 PM, Fang Yidong <fangyidong@...> wrote:
>
>> Maybe, but not necessarily, because this information if implicit
>> within call stack (except for having to track end markers).
>
>> That is, it's a recursive-descent kind of approach where you know
>> where you came from, usually without additional tracking of location.
>> Code branches based on constructs encountered.
>
> Yes, it's convenient. But I think it may result in a call stack based
processor instead of a heap based
> one, right? The former will cause stack overflow issues in a deep nesting
level. Here's a heap

Yes, if your document has nesting level of about million or so. :-D
So I don't think that is a practical concern.

If it happens to be, then one can construct explicit stack, similar to
how one has to do it with SAX-like interfaces.

> based processor for building object graph with SAX-like interface:
>
http://code.google.com/p/json-simple/wiki/DecodingExamples#Example_6_-_Build_who\
le_object_graph_on_top_of_SAX-like_content

Right: that builds "poor man's object binding", List/Map/primitive
structure from Json.
Most Json parsers offer that functionality via API, so it need not be
built from low-level components (json.org and others).
Code with pull API would be quite similar, although one could choose
between recursion and iteration with explicit stack.

-+ Tatu +-

Ah I am sorry I was not clear we provide the JSON and XML
tools to C++ users not Java.
http://www.p6r.com/articles/2008/05/22/a-sax-like-parser-for-json/




On Sat, 7 Feb 2009 19:10:21 -0800
   Tatu Saloranta <tsaloranta@...> wrote:
> On Sat, Feb 7, 2009 at 4:25 PM, Mark Joseph
><mark@...> wrote:
>> I was reading over the StAX specification and BEA
>>provides
>> licenses to the API, but that license prevents
>> sublicenses.  This means I as a vendor cannot provide my
>> own implementation and license that to customers.   So
>>if
>
> I don't see why you would need a license to implement an
>API.
> Generally licensing governs usage of API itself,
>distributing it, modifying etc.
> None of those are usually needed, because Stax is part
>of JDK 1.6.
> Or you point users to download API jar itself from
>whoever can provide it.
>
> Also: whatever stax specs download bundle claims is
>probably incorrect.
>
> But yes, clearly BEA screwed up licensing mentions and
>other parts.
>
>> I am reading that right what is the point of that
>> standard?
>> We at P6R provide JSON and XML tools (amoung others),
>>but
>> if the standard has restrictions on it then its not a
>>real
>> standard that we can use.
>
> Just to be clear: Stax API itself has little to do with
>Json. It is a
> Java xml processing API, and would be of little help for
>Json. There's
> no point in trying to implement it, due to fundamental
>differences
> between xml and json data formats.
>
> But similar style ("pull parsing") is useful.
>
> -+ Tatu +-

-------------------------
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, Feb 7, 2009 at 8:35 PM, Mark Joseph <mark@...> wrote:
> Ah I am sorry I was not clear we provide the JSON and XML
> tools to C++ users not Java.
> http://www.p6r.com/articles/2008/05/22/a-sax-like-parser-for-json/

Ok that explains it. I shouldn't have assume it's for Java either.
And it is true that for products that cover both xml and json, it is
advantageous to use same or similar interfaces too. There are some
java libraries that do something similar, such as jettison that
exposes json through java xml interfaces (stax in this case).

-+ Tatu +-

I have updated the JSONRequest proposal, removing the Origin feature.
I have been persuaded that it can encourage bad practice.

http://json.org/JSONRequest.html

--- In json@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> I am proposing a new mechanism for doing data transport in Ajax/Comet
> applications. It is called JSONRequest. It is a minimal communications
> facility that can be exempted from the Same Origin Policy.
>
> You can read about it here: http://json.org/JSONRequest.html
>

This question may have been asked previously but a quick search didn't
turn up anything. Why does JSONRequest only support GET/POST and
propose a new CANCEL request? What of PUT and DELETE? I can see how
JSONRequest would be extremely useful for RESTful web services and I'm
curious as to why you are proposing yet another protocol on top of
HTTP when HTTP already provides the necessary verbs and
exceptions/error codes. Wouldn't it be expedient to work within the
existing HTTP specification? My apologies if this has already been
addressed, I've arrived a little bit late to the discussion.

- Dave

On Mon, Feb 16, 2009 at 12:10 AM, pigwin32 <pigwin32@...> wrote:
> --- In json@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>>
>> I am proposing a new mechanism for doing data transport in Ajax/Comet
>> applications. It is called JSONRequest. It is a minimal communications
>> facility that can be exempted from the Same Origin Policy.
>>
>> You can read about it here: http://json.org/JSONRequest.html
>>
>
> This question may have been asked previously but a quick search didn't
> turn up anything. Why does JSONRequest only support GET/POST and
> propose a new CANCEL request? What of PUT and DELETE? I can see how
> JSONRequest would be extremely useful for RESTful web services and I'm
> curious as to why you are proposing yet another protocol on top of
> HTTP when HTTP already provides the necessary verbs and
> exceptions/error codes. Wouldn't it be expedient to work within the
> existing HTTP specification? My apologies if this has already been
> addressed, I've arrived a little bit late to the discussion.

I am not a REST expert, but isn't PUT used to store given payload (in
this case, request in form of Json), and DELETE just ignore payload?
Meaning that such operations via JSONRequest wouldn't make much sense;
after all, you can call PUT with appropriate content type anyway, and
DELETE wouldn't require one.

That is: what would be useful semantics for such operations? (same
could be asked of GET -- but I assume that's for manual testing via
browser)

I guess case could be made that for completeness sake these verbs
should be supported.

-+ Tatu +-

VTD-XML 2.5 is now released. Please go to
https://sourceforge.net/project/showfiles.php?
group_id=110612&package_id=120172&release_id=661376
   to download the latest version.


Changes from Version 2.4 (2/2009)

* Added separate VTD indexing generating and loading (see
http://vtd-xml.sf.net/persistence.html for further info)
* Integrated extended VTD supporting 256 GB doc (In Java only).
* Added duplicateNav() for replicate multiple VTDNav instances sharing
XML, VTD
and LC buffer (availabe in Java and C#).
* Various bug fixes and enhancements

Hello Tatu,

While I was googling JSON.simple usage, I occasionally find
JsonSimpleDriver.java in svn of codehaus, and the benchmark results, comparing
with Jackson and other libraries. I think that it's your work?

The throughput of Jackson is high definitely and I really think Jackson is an
excellent StAX JSON parser.

I am writing to you because I'd like to share some of my opinions on the testing
itself. I know that you haven't pulished the results yet, here's just some
discussions.

Here's my opinions:
1. I think different libraries accept different inputs, such as a byte array, a
string, a inputstream or a reader, so the preparation of such input objects
should be prepared in the warm up stage, not the running.

2. I think the iteration of the resulting graph is not a part of the parser and
should not be put in the run method, but some minor operations can be performed
to verified that the result is a correct one.

3. Could you also help to test the SAX-like interface of JSON.simple in the way
of JacksonDriverStreaming.java did?聽

I think your work will definitely help to improve the qualities of all JSON
libraries.

Thanks.

Yidong Fang




       ___________________________________________________________
   濂界帺璐哄崱绛変綘鍙戯紝閭璐哄崱鍏ㄦ柊涓婄嚎锛�
http://card.mail.cn.yahoo.com/

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

Sorry this message is intended to send to Tatu only. My bad.
Since the result is not published yet, let's discuss it privately.












             Hello Tatu,



While I was googling JSON.simple usage, I occasionally find JsonSimpleDriver.
java in svn of codehaus, and the benchmark results, comparing with Jackson and
other libraries. I think that it's your work?



The throughput of Jackson is high definitely and I really think Jackson is an
excellent StAX JSON parser.



I am writing to you because I'd like to share some of my opinions on the testing
itself. I know that you haven't pulished the results yet, here's just some
discussions.



Here's my opinions:

1. I think different libraries accept different inputs, such as a byte array, a
string, a inputstream or a reader, so the preparation of such input objects
should be prepared in the warm up stage, not the running.



2. I think the iteration of the resulting graph is not a part of the parser and
should not be put in the run method, but some minor operations can be performed
to verified that the result is a correct one.



3. Could you also help to test the SAX-like interface of JSON.simple in the way
of JacksonDriverStream ing.java did?聽



I think your work will definitely help to improve the qualities of all JSON
libraries.



Thanks.



Yidong Fang




















       ___________________________________________________________
   濂界帺璐哄崱绛変綘鍙戯紝閭璐哄崱鍏ㄦ柊涓婄嚎锛�
http://card.mail.cn.yahoo.com/

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

On Thu, Feb 19, 2009 at 11:08 PM, Fang Yidong <fangyidong@...> wrote:
> Hello Tatu,
>
> While I was googling JSON.simple usage, I occasionally find
JsonSimpleDriver.java in svn of codehaus, and the benchmark results, comparing
with Jackson and other libraries. I think that it's your work?

Hi there! Yes, that is true.

>
> The throughput of Jackson is high definitely and I really think Jackson is an
excellent StAX JSON parser.
>
> I am writing to you because I'd like to share some of my opinions on the
testing itself. I know that you haven't pulished the results yet, here's just
some discussions.

Sure, thank you for your input. I hadn't yet published it, but it is
of course public from the blog.

>
> Here's my opinions:
> 1. I think different libraries accept different inputs, such as a byte array,
a string, a inputstream or a reader, so the preparation of such input objects
should be prepared in the warm up stage, not the running.

Hmmh. I don't think I fully agree, but I agree in that it depends on use case.

For me, the use case is always getting Json from an external source
(network request, from file system), and hence input is naturally a
stream of bytes. So if a library just takes a String, it must be
constructed from bytes.
I did give shortcuts for some parsers so that there was no need to
read from the stream, so in a way some parsers benefited from the
setup (from my perspective).

It is possible that other use cases could be ones where a String would
be needed anyway (like perhaps reading it from a DB), but for me this
is not the case.

> 2. I think the iteration of the resulting graph is not a part of the parser
and should not be put in the run method, but some minor operations can be
performed to verified that the result is a correct one.

I think needs to be, because otherwise you can not do anything of use;
and parsers could optimize away some processing.
I don't think results would differ a lot though, most parsers do
handle all the data independent of traversal. I can probably make this
configurable to see what the difference is.

> 3. Could you also help to test the SAX-like interface of JSON.simple in the
way of JacksonDriverStreaming.java did?

Ah yes. Apologies for not trying it out -- I forgot that json.simple
does in fact have a streaming interface. I can add that, and make it
the main interface.

> I think your work will definitely help to improve the qualities of all JSON
libraries.

Thank you, and thanks for feedback!

-+ Tatu +-

On Thu, Feb 19, 2009 at 11:14 PM, Fang Yidong <fangyidong@...> wrote:
> Sorry this message is intended to send to Tatu only. My bad.
> Since the result is not published yet, let's discuss it privately.

(took the discussion offline, but if anyone is interested in what
results we are discussing, those are at:

http://www.cowtowncoder.com/blog/archives/2009/02/entry_204.html

I will be making some updates; and if any owners of other packages
have suggestions, let me know as well. Benchmarks are hard to do well
with different use cases and emphasis, so at least I want to document
presumptions and biases.

-+ Tatu +-

Dear all,

I am pleased to announce the publication of a new open source product,
jyson, a pure java JSON codec for jython 2.5.

You can access source code, documentation, etc, for jyson here

http://jyson.xhaus.com

If you're wondering what benefit using jyson brings over other
available JSON codecs, please see the Jyson FAQ

http://opensource.xhaus.com/projects/jyson/wiki/JysonFaq

Regards,

Alan Kennedy.

Hi.  I'm using JSON with JQGrid in an inquiry program.  I'm building a JSON
string with the server-side program, and the string contains an HTML hyperlink
tag.  Thus, the string should look something like this:

{"rows":[
{"divisionNumber":"4","divisionName":"<a
href=\"inv0004?productGroup=\"WFB\"&division=\"4\">MONTGOMERY - NEW
STEEL</a>","onHandWeight":"336660.28","percentOfTotal":"3.74","perLbCost":".45",\
"avgMonthlyWeight":"223615","monthsSupply":"3.37","turnoverRate":"4.69"}]}

This string works enough.  The link show up, but when I click on it, it takes me
to a URL of "inv0004?productGroup=".  Is there another character that needs to
be escaped?

It's valid JSON but not HTML. You're effectively closing the href attribute with
the first \" in the URL.

First off, it's is going to be an issue because you're nesting unescaped quotes
in a quoted string.  To do that in a JSON string you'd need an extra backslash
to escape the backslash. '\"' becomes '\\"'.  But in HTML, you'd actually need
to encode a quote with '"e;'

But your next problem is URLs aren't supposed to have unescaped quotes.  You
should instead replace '\"' with '%22'.

It looks like the root of your issue is that you're using string concatenation
to build up your result rather than proper encoding.

--- In json@yahoogroups.com, "violinssoundcool" <violinssoundcool@...> wrote:
>
> Hi.  I'm using JSON with JQGrid in an inquiry program.  I'm building a JSON
string with the server-side program, and the string contains an HTML hyperlink
tag.  Thus, the string should look something like this:
>
> {"rows":[
> {"divisionNumber":"4","divisionName":"<a
href=\"inv0004?productGroup=\"WFB\"&division=\"4\">MONTGOMERY - NEW
STEEL</a>","onHandWeight":"336660.28","percentOfTotal":"3.74","perLbCost":".45",\
"avgMonthlyWeight":"223615","monthsSupply":"3.37","turnoverRate":"4.69"}]}
>
> This string works enough.  The link show up, but when I click on it, it takes
me to a URL of "inv0004?productGroup=".  Is there another character that needs
to be escaped?
>

On Mon, Mar 23, 2009 at 12:53 PM, Stephen M. McKamey <jsonml@...> wrote:
...
> It looks like the root of your issue is that you're using string concatenation
to build up your result rather than proper encoding.

This does seem to be the case, and if so, I agree that it's time to
use a proper json encoder.

Just as with xml, one should never use plain old string concatenation
for producing content. Sometimes it's necessary to create/edit json
(xml) by hand, but if it's done programmatically, proper tools should
be used.
Same goes for parsing, too, but most developers pick up that side more
easily. :)

-+ Tatu +-