Re: What is the logic of storing XML in a Database?

On 29 mar, 20:26, "Marshall" <marshall.spi..._at_gmail.com> wrote:
> On Mar 29, 9:43 am, "Cimode" <cim..._at_hotmail.com> wrote:
>
>
>
> > On 29 mar, 17:29, "Marshall" <marshall.spi..._at_gmail.com> wrote:
>
> > > I strongly agree.
>
> > > I'll go a bit further. I imagine a world where the schema that
> > > a given piece of client software is embedded in that client.
> > > When it connects with the dbms, it tell the dbms the schema
> > > it expects, and the dbms dynamically constructs a view for
> > > that client, if possible.
>
> > > Marshall
>
> > If you allow me I shall go further in your dream...
>
> > In such word, each client routine code would be as simple as
>
> > Pull.db1(schema1)
>
> > where *schema1* would contain all query information characteristics.
>
> I think of it as being something implicit, rather than explicit.
> When you execute a client program, the runtime can inspect
> the client and issue the "Pull()" to the dbms at connect time.
Yes. That would indeed constitute an efficient form of caching.

> > The client would have also presentation routines that would allow it
> > to bind the schema to any kind of local presentation method.
>
> Yes yes!
>
> And these bindings would be declarative, and probably
> expressed as relations. And they could be dynamic, such
> that if you have a table widget bound to a table/view/query,
> as the table was updated, that would be reflected in
> the contents of the widget, dynamically.
I like the *widget* name for presentation routine. Not only it would present up to date information to user but it would have also have the advantage of versatility. The binding protocol would of course allow to bind several widgets to the same relation.

> > Periodically, clients would be able to gather existing schemas
> > according to areas of interest using simple routines such as
>
> > Pull.(AllSchema, AreaofInterest)
>
> > Given the amount of space and resources saved, the client could easily
> > and punctually renew such schemas...Some kind of language would
> > require to be created for that (or maybe an extension of a relationnal
> > querying language)...
>
> I didn't quite understand this part. I usually think of clients as
> having the schema they are written against "built-in." This
> makes it sound like clients are using dynamic schema.
> That makes sense for ad hoc queries but not so much for
> client code, which I think of as fixed.
I was thinking of the possibility of renewing schemas periodically to allow the inclusion of new querying capabilities depending on areas of interest of users. For instance, imagine that the client would have *core* routines that would allow it for instance to get the weather at any time. Then imagine that a user passing by a stock market wireless point of access could automatically get the ability to pull out *finance* related information thanks to the periodic induction of short life span schemas...
> Marshall
Received on Thu Mar 29 2007 - 21:09:07 CEST