In SVN, see http://pastebin.com/7Tkichnf

For a FooArray element, the array items are FooArrayItem.

I will fix the ContextMap's "item" name later.

Gary


On Wed, May 14, 2014 at 12:22 PM, Ralph Goers <ralph.go...@dslextreme.com>wrote:

> What about ContextStack, ExtendedStackTrace and Suppressed?
>
> Ralph
>
> On May 14, 2014, at 8:32 AM, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> OK, fixed in SVN. We now generate:
>
> <Marker name="Marker1">
>     <Parents>
>         <Marker name="ParentMarker1">
>             <Parents>
>                 <Marker name="GrandMotherMarker"/>
>                 <Marker name="GrandFatherMarker"/>
>             </Parents>
>         </Marker>
>         <Marker name="ParentMarker2"/>
>     </Parents>
> </Marker>
>
> Gary
>
>
> On Wed, May 14, 2014 at 10:27 AM, Gary Gregory <garydgreg...@gmail.com>wrote:
>
>> You're right, it's weird that all the elements are called "Parents".
>>
>> Gary
>>
>>
>> On Wed, May 14, 2014 at 3:02 AM, Ralph Goers 
>> <ralph.go...@dslextreme.com>wrote:
>>
>>> Oops. Having said that and then looking at the XML example there are
>>> obvious problems.  The Marker element has a Parents container element that
>>> contains another Parents element that has a name attribute?  I would guess
>>> the inner Parents should be Parent?  Having said that,  I would have
>>> expected that a Marker element would contain other Marker elements, perhaps
>>> in a Parents container, such as
>>>
>>>
>>>    1.         <Marker name="Marker1">
>>>    2.                 <Parents>
>>>    3.                         <Marker name="ParentMarker1">
>>>    4.                                 <Parents>
>>>    5.                                         <Marker name=
>>>    "GrandMotherMarker"/>
>>>    6.                                         <Marker name=
>>>    "GrandFatherMarker"/>
>>>    7.                                 </Parents>
>>>    8.                         </Marker>
>>>    9.                         <Marker name="GrandFatherMarker"/>
>>>    10.                 </Parents>
>>>    11.         </Marker>
>>>
>>>
>>> Then there is ContextStack. I would have expected:
>>>
>>>
>>>    1.         <ContextStack>
>>>    2.                 <StackItem>stack_msg1</StackItem>
>>>    3.                 <StackItem>stack_msg2</StackItem>
>>>    4.         </ContextStack>
>>>
>>>
>>> Having a ContextStack element that is a container for other ContextStack
>>> elements that contain values is confusing.
>>>
>>> Likewise I would expect ExtendedStackTrace to contain StackTraceItems or
>>> StackTraceElements, not other ExtendedStackTrace elements.
>>>
>>> The same is true of Suppressed.
>>>
>>> Ralph
>>>
>>>
>>>
>>>
>>> On May 13, 2014, at 11:53 PM, Ralph Goers <ralph.go...@dslextreme.com>
>>> wrote:
>>>
>>> Sorry, I meant an example of how the JSON looks with these cases.  I am
>>> less concerned with the XML.
>>>
>>> Ralph
>>>
>>> On May 13, 2014, at 10:23 PM, Gary Gregory <garydgreg...@gmail.com>
>>> wrote:
>>>
>>> Here is an example for the current XML: http://pastebin.com/cLbuwe4b
>>>
>>> Gary
>>>
>>>
>>> On Tue, May 13, 2014 at 10:53 PM, Ralph Goers <rgo...@apache.org> wrote:
>>>
>>>> Can you post an example?
>>>>
>>>> Sent from my iPad
>>>>
>>>> On May 13, 2014, at 6:51 PM, Gary Gregory <garydgreg...@gmail.com>
>>>> wrote:
>>>>
>>>> This messages is about the format of tag names, not the shape of the
>>>> elements.
>>>>
>>>> Right now, I have XML elements names in CamelCase format and XML
>>>> attributes in camelCase format. Pretty standard.
>>>>
>>>> For JSON, I have both types of names as camelCase, but it makes the
>>>> code a little awkward to undertamd and maintain.
>>>>
>>>> So what I think I'm going to do is use the CamelCase for objects and
>>>> camelCase for primitives.
>>>>
>>>> This will give both the code and documents the same feel and it will
>>>> make it easier to understand (IMO).
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>> Java Persistence with Hibernate, Second 
>>>> Edition<http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second 
>>> Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second 
>> Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second 
> Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Reply via email to