On Thu, Jan 8, 2009 at 12:57 AM, Fang Yidong <fangyidong@...> wrote:
> It's base on some internal testing and  testing of an independent author in
some complex scenarios.
>
> The result show that the encoding of JSON.simple is as fast as Douglas's
implementation. The decoding is close to Douglas's implementation and faster
than some of the implementations, but slower than one or two of them.
>
> The testing may not cover all scenarios and may not be completely fair, but
provides some basic information.
>
> Hope there will be a public third party testing.

Thank you for quick answer! Would it be maybe possible to publish
results of these internal tests? And/or maybe just cut'n paste your
explanation -- it helps a lot in understanding what has been measured.
For what it's worth, json.org's reference implementation is not among
the fastest parsers, but I guess it is a reasonable baseline to
compare against.

I can probably help with testing, too, since I do have a test suite I
have used previously (but not with json.simple since I didn't know of
its existence).

-+ Tatu +-

It will be great if you can add JSON.simple (latest version 1.0.2) in your test
suite and let me know the results.

I'll publish the testing source codes and results if appropriate, later.
 
Thanks.
 
--
JSON: Action in AJAX!

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

---






On Thu, Jan 8, 2009 at 12:57 AM, Fang Yidong <fangyidong@yahoo. com.cn> wrote:
> It's base on some internal testing and testing of an independent author in
some complex scenarios.
>
> The result show that the encoding of JSON.simple is as fast as Douglas's
implementation. The decoding is close to Douglas's implementation and faster
than some of the implementations, but slower than one or two of them.
>
> The testing may not cover all scenarios and may not be completely fair, but
provides some basic information.
>
> Hope there will be a public third party testing.

Thank you for quick answer! Would it be maybe possible to publish
results of these internal tests? And/or maybe just cut'n paste your
explanation -- it helps a lot in understanding what has been measured.
For what it's worth, json.org's reference implementation is not among
the fastest parsers, but I guess it is a reasonable baseline to
compare against.

I can probably help with testing, too, since I do have a test suite I
have used previously (but not with json.simple since I didn't know of
its existence).

-+ Tatu +-















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

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

Doug, I realized that I hadn't sent you note about Jackson json
processor moving to Codehaus.
Could you update the link at json.org to point to:

http://jackson.codehaus.org

(the old page is still there and will redirect, so it's not a huge
deal, but eventually it'll move over completely)

Also: on a related note, would it make sense to start
classifying/grouping projects more on that page? Or adding some
tagging to indicate rough functionality. Right now level of json
functionality for Java libs varies a lot, for example: some libraries
are for xml processing but also expose interoperability functionality
for json; whereas others are json parsers, data binding packages and
so on.

-+ Tatu +-

--- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
>
> Doug, I realized that I hadn't sent you note about Jackson json
> processor moving to Codehaus.
> Could you update the link at json.org to point to:
>
> http://jackson.codehaus.org

Updated. Thanks.

> Also: on a related note, would it make sense to start
> classifying/grouping projects more on that page? Or adding some
> tagging to indicate rough functionality. Right now level of json
> functionality for Java libs varies a lot, for example: some libraries
> are for xml processing but also expose interoperability functionality
> for json; whereas others are json parsers, data binding packages and
> so on.

Would you like to propose something?

The Python community was able to converge on a single library. The
Java community has not yet, as far as I can tell, shown any intention
to converge.

On Fri, Jan 16, 2009 at 1:26 PM, Douglas Crockford
<douglas@...> wrote:
> --- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
>>
>> Doug, I realized that I hadn't sent you note about Jackson json
>> processor moving to Codehaus.
>> Could you update the link at json.org to point to:
>>
>> http://jackson.codehaus.org
>
> Updated. Thanks.

Thank you.

>> Also: on a related note, would it make sense to start
>> classifying/grouping projects more on that page? Or adding some
>
> Would you like to propose something?
>
> The Python community was able to converge on a single library. The
> Java community has not yet, as far as I can tell, shown any intention
> to converge.

I think convergence will happen via sort of natural selection over
time... although it might not be bad to have one or more APIs similar
to SAX/Stax. So for now it's ok to let all flowers bloom. :)

My suggestion would be more modest: to try to indicate what kind of
things libs are capable of, to help users more easily find what they
are looking for.
This is partly due to high number of json processing tools available
on java platform.

-+ Tatu +-

The JSON.stringify function builds a JSON text using the own
properties of the objects it is given. If you want the text to also
include the inherited properties, then you can provide a replacer
function parameter that causes all of the members to be included. For
example,

JSON.stringify(n, function replacer(key, value) {
     var i, new_value;

     switch (typeof value) {
     case 'function':
     case 'undefined':
         return;
     case 'object':
         if (value &&
                 Object.prototype.toString.apply(value) !==
                      '[object Array]') {
             new_value = {};
             for (i in value) {
                 new_value[i] = value[i];
             }
             return new_value;
         }
         return value;
     default:
         return value;
     }
} , 4)

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]