Graphviz Tool: No CND input files?

[Wolf Benz <eu...@gmail.com>]

Hi List, I just came across this link:
http://jackrabbit.apache.org/doc/nodetype/visualization.html

from that page I understand that we have yet another reason to abandon
CND in favor of the proper XML notation. (validation in IDEs being the
other biggy. If only someone had a proper XSD file!)
Is this correct or does it also accept CND files? (My guess is no, as
an XSLT is used)

Wolf

Re: Graphviz Tool: No CND input files?

[David Nuescheler <da...@gmail.com>]

--- Jukka wrote:
> It's possible to implement editor and validation support CND files,
> but there's no way to make the XML notations more readable without
> special illustration tools like mentioned above.
Very well put.
Bravo!

regards,
david

Re: Graphviz Tool: No CND input files?

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 2/14/07, Wolf Benz <eu...@gmail.com> wrote:
> I've asked this before, but do you know of an up to date XSD that
> could be used for XML Node Type Defs editing? (if such schema exists,
> no tools have to made)

Unfortunately no. I'd be happy to accept such a contribution, but as
of now I don't know of anyone actively working on XML node type
notations.

BR,

Jukka Zitting

Re: Graphviz Tool: No CND input files?

[Wolf Benz <eu...@gmail.com>]

Thanks for your replies Jukka.
I've asked this before, but do you know of an up to date XSD that
could be used for XML Node Type Defs editing? (if such schema exists,
no tools have to made)
Thx,
Wolf

>
> Depends on your priorities. I personally consider ease of
> communicating node type designs  a higher priority than ease of
> editing the design files. Luckily Jackrabbit supports both CND and the
> XML nodetype notation, so there's basically no stopping you from using
> XML if that's what you prefer. Unfortunately there is even less
> documentation on the XML notation than on CND... :-(
>
> BR,
>
> Jukka Zitting
>

Re: Graphviz Tool: No CND input files?

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 2/14/07, Wolf Benz <eu...@gmail.com> wrote:
> -- I read that, but failed to understand what it meant. What is meant
> with a "system view export" ?

JCR specifies two XML formats, "document" and "system" view, for
importing and export content to and from a content repository. A
"system view export" is the XML document that results from a call to
Session.exportSystemView() with the specified node path, in this case
"/jcr:system/jcr:nodeTypes".

> I'd love a more elaborated explanantion on the website. I guess if I don't
> know what it means, a lot other newies won't get it either.

Good point, and I agree that we are still short on documentation. The
JCR specification itself is the best place for now to look for
information like this.

> -- No argument there. Yet, being a JCR-beginner, I care more about the
> correctness of my node defs than I care about it being more concise.
> And with this, the XML helps twofold as it also is more verbose. If
> only because it tells you what is inside. (e.g. <supertypes> ... </>
> etc)

I'd argue that the

> - We are somehow told to use a cnd file. Yet no way to validate it.
> The conversion tools to/from XML are not complete.

Agreed, there's still much to be done. The best way to speed things up
is to file feature requests for the missing tools in the issue
tracker.

> - XML is not bad. I think with XML AND smart defaulting we would get
> very far, also wrt conciseness.

All contributions are welcome. :-)

> All this smells like reinventing the wheel for the sake of
> conciseness. That's a very high price tag. Unless you're very familiar
> with the format, is it really worth it?

Depends on your priorities. I personally consider ease of
communicating node type designs  a higher priority than ease of
editing the design files. Luckily Jackrabbit supports both CND and the
XML nodetype notation, so there's basically no stopping you from using
XML if that's what you prefer. Unfortunately there is even less
documentation on the XML notation than on CND... :-(

BR,

Jukka Zitting

Re: Graphviz Tool: No CND input files?

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 2/14/07, David Nuescheler <da...@day.com> wrote:
> Early on in the process, there is nothing but the spec. Tools and
> tutorials always come later. I am thrilled to see that Jackrabbit and
> JCR continues to evolve and attracts more than "just early adopters".
>
> I think we are in agreement that tutorial style documentation and
> tooling is very important to the growth JCR and Jackrabbit to become
> "mainstream".

What an excellent excuse for me to shamelessly advertise the upcoming
ApacheCon EU in Amsterdam! :-) See http://www.eu.apachecon.com/ for
more information.

Assuming good enough attendance I will be giving a half-day tutorial
on "JCR Content Management" on Tuesday, May 1st. See below for the
abstract:

    How to build content applications with JCR? This hands-on tutorial
    shows how to use the flexible and feature-rich Content Repository
    for Java Technology API (JCR) for content management. The tutorial
    starts with a brief introduction to the JCR API and continues to
    build an example content application (a web-based music store) based
    on Apache Jackrabbit. Topics discussed include content repository
    setup, JCR content modeling and best practices, architecture of
    JCR content applications, and the basic features of JCR. Advanced
    JCR features like versioning and observation are covered based on
    the interests of the audience.

See you there!

BR,

Jukka Zitting

Re: Graphviz Tool: No CND input files?

[David Nuescheler <da...@day.com>]

Hi Wolf,

> > As mentioned above, feel free to use the system view as pointed
> > out by Jukka.
> -- I'm not sure I get what you mean here. How does this help me to
> edit a Node Defs in a easy(validated correctness and autocompletioned)
> way?
I think you are looking for tooling really. Maybe something along the lines of
http://jsr170tools.day.com/crx/nodetypes/index.jsp might help you.

> > I think I slowly get the feeling that you have not been exposed to the JCR spec
> > yet.
> -- Oh I haven't. That's true. Should I? If that's a requirement for
> anyone to start with JCR, I'm afraid the treshhold is really pushed
> quite high.
Well, it is a requirement developers have an understanding of
the API that they are using. Now, if you get that knowledge through
going through a training, by reading a book (which does not
exist for JCR yet) or by reading the spec is up to you.

I think it is to be expected that the number of educational options
are more limited for new technologies, but will grow over time.
The reason why is mention the spec is because it is available
from the very beginning.

> We all have so little time. This is smth new. New stuff often starts
> after the hours, by a few crazy volunteers, and with a lot of
> goodwill. A helpful website to get you really started well with the
> basics explained like Node Defs + some tools around that, seems a
> current void. I'm not saying the JR site is not helpful.
...and I am not saying that it is perfect. I guess that's the beauty of
a community open source project. As Jukka put it: Contributions
(also to the documentation and the website) are always welcome.

> Truth be told, it would also be the first time in 15 yrs I would
> actually have to read the spec itself to get to the info I need.
I think this is a very interesting statement and I think it might
have something to do with the fact that you usually start to work
with technologies relatively late in their evolutionary stages,
when tooling and tutorials already exist to their full extent.

Early on in the process, there is nothing but the spec. Tools and
tutorials always come later. I am thrilled to see that Jackrabbit and
JCR continues to evolve and attracts more than "just early adopters".

I think we are in agreement that tutorial style documentation and
tooling is very important to the growth JCR and Jackrabbit to become
"mainstream".

> I hope rather sooner than later someone is sponsored to write a decent
> book on the topic. With lots of examples.
> Anyone know of someone being in the process of such an effort? (book)
We are working on a JCR book but the more the merrier. Feel free to
make your voice heard to the "publishers" ;)

> -- Having one that works fine will do. From a user's prespective, I
> care less on the "how" part. Our business is not JCR but the business
> we build with it :-) (sounded harsh so I added a smiley :-)
I think that's a great quote. It really stresses the "intrastructure" direction
that JCR should be taking.

> > We are in good company to encounter that the XML notations yield
> > undesirable results.
> > Even at the heart of the XML community people are
> > not (only) using XML, take RelaxNG [2], XQuery or XPath for that matter.
> -- There exist tools to help you with those. Not for CND. (at least
> not that I know of, in eclipse)
You may be interested in http://www.day.com/eclipse/
Work in progress though, but it may show to you that we are on the
same page, it is just about timing, I guess.

regards,
david

Re: Graphviz Tool: No CND input files?

[Wolf Benz <eu...@gmail.com>]

Hi david :-)

> If you would like to read up on the argument around this please
> find some information here:
> http://jackrabbit.apache.org/doc/nodetype/cnd.html

-- I had read it. (in fact it was lying in front of me while sending
the reply to the List :-)
Yet it failed to convince me as consiceness is not my first problem.
(no offense meant - I already gave my point of view)

> As mentioned above, feel free to use the system view as pointed
> out by Jukka.

-- I'm not sure I get what you mean here. How does this help me to
edit a Node Defs in a easy(validated correctness and autocompletioned)
way?

> I think I slowly get the feeling that you have not been exposed to the JCR spec
> yet.

-- Oh I haven't. That's true. Should I? If that's a requirement for
anyone to start with JCR, I'm afraid the treshhold is really pushed
quite high.
We all have so little time. This is smth new. New stuff often starts
after the hours, by a few crazy volunteers, and with a lot of
goodwill. A helpful website to get you really started well with the
basics explained like Node Defs + some tools around that, seems a
current void. I'm not saying the JR site is not helpful. On the
contrary even, it's the best one available as we speak and what I have
so far is entirely tahnks to teh JR site. Yet for people like me to
get rfully started, it lacks vital parts and info. Perhaps missing
parts could be copyt-pasted-stripped from the spec itself? (don't know
whether it lends itself to it)
Truth be told, it would also be the first time in 15 yrs I would
actually have to read the spec itself to get to the info I need. I
hope rather sooner than later someone is sponsored to write a decent
book on the topic. With lots of examples. (In the mean time David, we
are of course going to follow the 4-d course dev @ Day ;-)
Anyone know of someone being in the process of such an effort? (book)

> Anyway, I think that having an Eclipse plugin that lets you
> manipulate nodetype definitions would be a great thing.
> I don' t think that this should be tied to any language though
> but should use the programmatic interfaces provided by
> the repository anyway.

-- Having one that works fine will do. From a user's prespective, I
care less on the "how" part. Our business is not JCR but the business
we build with it :-) (sounded harsh so I added a smiley :-)


> Let me put it this way: We tried XML and we even kept the XML
> notations around in the form of the system view export.
> ... however, personally I find it very unreadable.

-- Did someone make an XSD file we could use now?

> We are in good company to encounter that the XML notations yield
> undesirable results.
> Even at the heart of the XML community people are
> not (only) using XML, take RelaxNG [2], XQuery or XPath for that matter.

-- There exist tools to help you with those. Not for CND. (at least
not that I know of, in eclipse)

Wolf

Re: Graphviz Tool: No CND input files?

[David Nuescheler <da...@gmail.com>]

Hi Wolf,

> -- I read that, but failed to understand what it meant. What is meant
> with a "system view export" ? I'd love a more elaborated explanantion
> on the website. I guess if I don't know what it means, a lot other
> newies won't get it either.
Jukka is refering to the standard xml mappings of JCR,
Section 6.4.1 of the JCR v1.0 spec (page 83 and following) [1].

> I'm afdraid to speed up JCR-adoption, this CND thing is a historic
> mistake. Look at what we have now:
....as mentioned above there is an XML representation of nodetypes.

If you would like to read up on the argument around this please
find some information here:
http://jackrabbit.apache.org/doc/nodetype/cnd.html

> - We are somehow told to use a cnd file. Yet no way to validate it.
> The conversion tools to/from XML are not complete.
As mentioned above, feel free to use the system view as pointed
out by Jukka.

> - Autocompletion/showing existing options go through the window. E.g.
> what possibilities has jrc:xxx ?  I found some, scattered at various
> places, like jrc:encoding etc. But even on the JR site nobody bothered
> to put them together. Same for the other build-in names. (nt, mix, )
> An XSD solves this out of the box.
I think I slowly get the feeling that you have not been exposed to the JCR spec
yet.
I would strongly recommend reading the specification, you will find a
lot of the
information that you are looking for right there.

> - Coming out WITH a diffferent format yet WITHOUT a tool to work with
> it (in particular, like an eclipse plugin!) is like giving a car
> without the gaz. Where's the fun?
...let's agree on "without electronic park assist".

Anyway, I think that having an Eclipse plugin that lets you
manipulate nodetype definitions would be a great thing.
I don' t think that this should be tied to any language though
but should use the programmatic interfaces provided by
the repository anyway.

> All this smells like reinventing the wheel for the sake of
> conciseness. That's a very high price tag. Unless you're very familiar
> with the format, is it really worth it?
Let me put it this way: We tried XML and we even kept the XML
notations around in the form of the system view export.
... however, personally I find it very unreadable.

We are in good company to encounter that the XML notations yield
undesirable results.
Even at the heart of the XML community people are
not (only) using XML, take RelaxNG [2], XQuery or XPath for that matter.

regards,
david

[1] http://jcp.org/aboutJava/communityprocess/final/jsr170/index.html
[2] http://relaxng.org/compact-tutorial-20030326.html

Re: Graphviz Tool: No CND input files?

[Wolf Benz <eu...@gmail.com>]

> The visualization tool actually works on the system view export of
> /jcr:system/jcr:nodeTypes instead of CND, XSD, or the XML nodetype
> notation.

-- I read that, but failed to understand what it meant. What is meant
with a "system view export" ? I'd love a more elaborated explanantion
on the website. I guess if I don't know what it means, a lot other
newies won't get it either.

> Your point about CND vs. XSD or another XML notation for nodetypes has
> some merit, but in practice the CND notation is much more consise and
> readable.

-- No argument there. Yet, being a JCR-beginner, I care more about the
correctness of my node defs than I care about it being more concise.
And with this, the XML helps twofold as it also is more verbose. If
only because it tells you what is inside. (e.g. <supertypes> ... </>
etc)

I'm afdraid to speed up JCR-adoption, this CND thing is a historic
mistake. Look at what we have now:

- We are somehow told to use a cnd file. Yet no way to validate it.
The conversion tools to/from XML are not complete.

- Autocompletion/showing existing options go through the window. E.g.
what possibilities has jrc:xxx ?  I found some, scattered at various
places, like jrc:encoding etc. But even on the JR site nobody bothered
to put them together. Same for the other build-in names. (nt, mix, )
An XSD solves this out of the box.

- XML is not bad. I think with XML AND smart defaulting we would get
very far, also wrt conciseness. And... we'd use a format the rest of
the industry uses. (You think Spring would have gotten this far had
tthey used a special .sprg file?)

- Image the existing XML toolset. Graphviz is just one example but
there many. For CND this community will have to build their own
ecosystem around their own format.

- Coming out WITH a diffferent format yet WITHOUT a tool to work with
it (in particular, like an eclipse plugin!) is like giving a car
without the gaz. Where's the fun?

All this smells like reinventing the wheel for the sake of
conciseness. That's a very high price tag. Unless you're very familiar
with the format, is it really worth it?

Wolf

Re: Graphviz Tool: No CND input files?

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 2/14/07, Wolf Benz <eu...@gmail.com> wrote:
> Hi List, I just came across this link:
> http://jackrabbit.apache.org/doc/nodetype/visualization.html
>
> from that page I understand that we have yet another reason to abandon
> CND in favor of the proper XML notation. (validation in IDEs being the
> other biggy. If only someone had a proper XSD file!)
> Is this correct or does it also accept CND files? (My guess is no, as
> an XSLT is used)

The visualization tool actually works on the system view export of
/jcr:system/jcr:nodeTypes instead of CND, XSD, or the XML nodetype
notation.

Your point about CND vs. XSD or another XML notation for nodetypes has
some merit, but in practice the CND notation is much more consise and
readable. It works *much* better when for example copy-pasting
examples to the mailing list or when documenting the node types used
by an application.

It's possible to implement editor and validation support CND files,
but there's no way to make the XML notations more readable without
special illustration tools like mentioned above.

BR,

Jukka Zitting