OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Section 7.4


Message text written by Murata Makoto
>
I don't think you have spoken with database people.  When I gave a talk 
at WebDB, somebody asked about identity constraints in RELAX NG.  When I 
said that RELAX NG does not have multi-part keys, he said that such
identity constraints will not make the database community happy.  Nobody in

the room disagreed.

Let's face it.  The current spec is already very unsatisfactory for
database 
guys.  We will eventually need a different spec for identity constraints. 
If 
our mechanism is as simple as ID/IDREF/IDREFS of DTDs, we can say that it
is 
only for compatibility with DTDs.  If our key/keyRef is extremely
complicated, 
we cannot say so.<

>>>>>>>>>>>>>

Murata,

We have to face reality here.  We cannot please everyone.  Equally we
cannot
swamp the spec' with detail and complexity for this or that fringe - or
non-core
use case / requirement.   That defeats the purpose - of having something
simple
and consistent that meets the 80:20 rule.    We should say what RELAX is
NOT as
well as what it IS.

If the database guys want all this key stuff - let them go off and develop
RELAX DB
extensions or something.

Frankly I think this database stuff is a red-herring.  It's because people
are still 
steeped in RDBMS / SQL think - and they have not moved beyond that yet.
The future is adaptive information filtering driven off semantics and the
inherent
XML structural context.  The means to implement all this is separate and 
distinct from the XML instances and structural layer and should not be
confused
with it.

The real answer for XML accessing within an XML DB is XPath / XQuery et al 
and that clearly is the domain of other WG's.

My company has two DB/retrieval products for XML.  Both work directly off
the
XML instances, and yet utilize external extracted indexing to actually
drive the
querying.  Most every product has copied this approach.  And actually the 
MORE of IDREFs and cute tricks people use in their raw XML - the less
likely 
it is to be maintainable / supported; because they imagine all kinds of 
behaviours that are not there / sustainable OR would be more simply and
effectively achieved using an equivalent XPath joined query.

We have more than enough in the spec' already to support RELAX Parser level
referencial content.   Anything else is IMHO out of scope.

Sometimes when you give presentations you have to be blunt!   It's only
salesmen that say "Oh that? YES!  It's in there!".

DW.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC