[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