Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of mwaschkowski@gmail.com
 designates 64.233.166.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=PVdEcKrRA7X+sA0laZJG++Kb3Ra7KHqF25J1n4pqKgWwJh9NBKJevmQvsVKdUUtIa3Yl6nCJrJVz32D4LQLsBVqygH6J2s10GeaKAbkrXaH2B88ChVSyqv+TLcHF9cn+FJqeQvOUGF9FKxxMHpas/jNFebL9CL3UnnXc/sDPhKk=
Message-ID: <76a6ebd00707180915j23f15a93x8a346e26918953f5@mail.gmail.com>
Date: Wed, 18 Jul 2007 12:15:42 -0400
From: "Mark Waschkowski" <mwaschkowski@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: 7.4 Appendix D: JCR 1.0 XPath (Deprecated)
In-Reply-To: <5f211bd50707180050p3a719419s4cd1ce1c045b7149@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_67426_11697732.1184775342217"
References: <469CD2C6.6000905@yourmail.com>
	 <5f211bd50707170913j2679c06bi5b8549dd3157741e@mail.gmail.com>
	 <469D13B9.9080003@yourmail.com>
	 <5f211bd50707180050p3a719419s4cd1ce1c045b7149@mail.gmail.com>

------=_Part_67426_11697732.1184775342217
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

re: xml in the (computer) industry
XML *is* being widely used and will continue grow in usage for *data
interoperability*. You don't use SQL or file systems for data
interoperability, it doesn't even apply.

re: XQuery subset
Either a subset of XQuery could be defined, or XQuery could be an optional
part of the spec, and searching/querying was even mentioned in the first
part of the spec as optional! See 2.2 Goals:
"Finally, a number of independently optional features are defined
that a compliant repository may support. These are transactions,
versioning, observation, access control, locking and additional
support for searching. "

"Sorry, for me it doesn't look like re-inventing the wheel. AQM is not a
language."
This position does not make sense to me. AQM is most definitely re-inventing
the 'Query' wheel. XQuery is a standard for Querying hierarchical XML type
data sources. See http://www.w3.org/TR/xquery/ If a standard already exists
for querying, how is AQM not re-inventing the wheel? SQL2 is re-inventing
SQL, as SQL access is deemed important and worthy of support as its a
standard that we all know and can (I hope) easily apply to SQL2. JQOM is
inventing some new way of querying using objects, and I don't know what its
based on. As stated from the spec below, AQM has grammer and looks like a
language to me...regardless of the words used, its a way of querying data,
similar in concept to XQuery.

>From the spec:
"4.6.5.2 JCR-SQL2 Notation

JCRSQL2 is a mapping of the AQM to a string serialization based
on the SQL language.

The non-terminals in the JCR-SQL2 EBNF grammar correspond
namewise with the type names of the AQM grammar.

The semantics of each JCR-SQL2 production is therefore described
by reference to the semantics of the corresponding AQM type. The
two grammars are, however, entirely distinct and self- contained.
Care should be taken not to mix productions from one grammar
with those of the other. "

"For me, XPath was always quite complicated. I would probably get used
to it, but I prefer more verbose languages. "
Thats fine, but much of it is actually very straightforward. Your
preference, however, it not (sorry) germane to this discussion. What's
important is that SQL and Xpath were both supported in the original spec,
and XPath actually makes more sense given the API Model (see below).

"So in your view, JCR is an XML database? For me, JCR is:
- File System
- RDBMS
- LDAP
- Subversion"
Actually, according to the JCR 170 spec, its:
"2.1 Motivation
As the number of vendors offering proprietary content repositories
has increased, the need for a common programmatic interface to
these repositories has become apparent. The aim of the Content
Repository for Java Technology API specification is to provide such
an interface and, in doing so, lay the foundations for a true
industry-wide content infrastructure. "

'A common programmatic interface to repositories'. Please don't get the
implementation details mixed up with the spec.

As well, the spec has support for hierarchical and non-hierarchical models.
(See 2.2 Goals) However, the model of the spec is largely based on XML. XML
is referenced extensively in the spec, and the API is xml geared. Please see
the diagram on first page of chapter 4. The Repository Model for the basic
model. Furthermore, looking at the headings for 'Chapter 4. The Repository
Model' shows the XML-centric API:

-Hierarchy, with a root node
-Siblings
-Child Nodes
-Namespaces
-Paths
-Properties and attributes

None of these concepts (which are the basic model of the API) have ANY
relevance to SQL and RDBMs. The concepts are very clearly XML based, and
thats the way the API that was defined. Again, XPath and XQuery are a more
natural fit for this kind of API. SQL is a natural fit (and made for) tables
with columns and rows, but the API is NOT defined around those concepts is
it?

Its a big mistake IMHO that the new spec wants to move away from that which
it was clearly defined around (XML). Its a fundamental move to remove XPath
from the spec, a bad one, and it leaves all those that used it in limbo. The
point of a spec is to have a standard, and IMHO that standard shouldn't be
so closely tied to the implementation as it seems to be doing with SQL
support but removal of XPath support. Especially when the API model is
considered and the fact that SQL is dated and not an ideal fit with said
API.

I'm really hoping that the spec changes from this course as it seems so
incongruent with its roots.

Regards,

Mark


On 7/18/07, Thomas Mueller <thomas.tom.mueller@gmail.com> wrote:
>
> Hi,
>
> >> the entire industry moving towards XML data interoperability ...
> > MSWord save document as XML file
>
> I was just not sure what you meant with 'entire industry'. I agree XML
> is important for document processing (however I would have probably
> used JSON). But in my view, most data is still accessed using SQL or
> directly from the file system.
>
> > Full implementation would be too much, so subsets is the way to go.
>
> I think it would be great to define the exact subset of XQuery!
>
> > B.t.w. I integrated Saxon XQuery 1.0 engine into JCR 1.2.
>
> How does this work, does it convert XQuery to XPath?
>
> > >> But I strongly believe that AQM is a bad choice.
> > Because re-inventing the wheel again
>
> Sorry, for me it doesn't look like re-inventing the wheel. AQM is not
> a language.
>
> > XPath
>
> For me, XPath was always quite complicated. I would probably get used
> to it, but I prefer more verbose languages.
>
> > * AQM - design to work with JCR Object model and so has limited
> functionality
>
> What functionality are you missing?
>
> > To summarize all this I propose to use 'X' languages to work
> > with 'X' data structures.
>
> So in your view, JCR is an XML database? For me, JCR is:
> - File System
> - RDBMS
> - LDAP
> - Subversion
>
> > Just swap Derby with eXist ....
>
> So you suggest the Jackrabbit persistence should be an XML database?
> And you would remove support for RDBMS / file system persistence /
> Lucene? Wouldn't that be quite a big change and restriction?
>
> Thomas
>


-- 
Best,

Mark Waschkowski

------=_Part_67426_11697732.1184775342217--