[
Lists Home |
Date Index |
Thread Index
]
I'm sorry for a long letter, which in some parts contradicts
some of my previous letters, but I think that this discussion
could be placed into slightly different context.
Short Summary :
It is time to start the SQL for XML ( XQuery with Updates )
ball rolling ASAP.
1. XML needs it's SQL - ASAP,
2. Nothing comes as close as XQuery ( with updates ) and
3. No matter how long they will sit on XQuery - they
would not make it 'ideal', that's not possible.
End of Short Summary.
----- Original Message -----
From: "Dare Obasanjo" <kpako@yahoo.com>
> There is a difference between requiring XML schema and depending on XML
> schema. XQuery
>
> - uses the XML Schema type system
> - requires the user to use XML schema if they want typechecking for
complex
> types w.r.t updates. (Yes, I konw this is in the future)
>
> This seems to imply a dependence on XML schema from where I sit.
>
> Of course, now that I think about database vendors that implement XQuery
don't
> have to use XML schemas. All they have to do is push update validation to
the
> underlying repository and then they can use whatever schema langauge they
> want.
They can, but who is that brave CTO, who will give his premission
to build on proprietary schema language? These days, when
everything has to be called 'standard' ( and 'open source' ).
In my oppinion, those database vendors, who would not support
XQuery / XSD ( or at least XSLT ) are taking a significant risk,
and because XSLT has no updates ... Go XQuery!
<XQuery isA= "probably the first W3C 'mainstream' app">
Can somebody please explain me why XQuery is 'really bad'?
The only problem I have with it, is that it has a word 'type'
in it ( and I think that their non-XML-ish syntax
is not as good as terseXML ;-) , but thats ... actually ...
minor (?) because I can (?) use a subset of XQuery with
no types other, than 'string'.
I'm also not concerned with a possible problems with entities,
PIs or tricky namespaces cases, because I better not
to use those things anyway, they hit on a long run.
So why XQuery is 'really bad' for 'Joe developer', who
basically has some SQL conding experience, some
intuitive XML understanding - and that's it?
I think XQuery (with updates and perhaps
DOM-alike-binding to process the results,
of course) is close to 'ideal fit' for a mainsteam...
What I'm missing? Sorry for my stupidity.
</XQuery>
<changing context>
On another hand, because of the word 'type'
in XQuery, I think that XQuery has a good chance to
repeat the SQL -> MySQL pattern.
What I mean is:
It seems that for a small vendor it may make sense to implement
an 'untyped' subset of XQuery and that would result in
"MySQL pattern".
Is MySQL 'bad' ?
Hell no! It is fast, robust and it powers an army of websites.
Does the existance of MySQL make things more complex for
'the whole SQL' world?
Yes it does!
Was it possible to avoid this mess or to make it less painfull?
I think it was possible, if the big guys would play nice with
small vendors, so that 'SQL subsets' would get synchronized
across small vendors, for example. ( Same goes to
"Linux vs big UNIXes" )
Is it *really* possible for big guys to play nice
with small vendors? I think it is not. That would mean
that Linux / MySQL / perl / whatever (non-standard marginalia)
will always exist in this world.
Is it 'bad' or 'good' - I don't know. I understand the desire
of big vendors to provide a 'very good solution with
unlimited possibilities, because we can afford that'.
I understand the desire of small vendors to "implement
80/20 subset, because that's what people 'really need'
and because we can do that cheap - we can afford that".
I think nobody can stop all this. How can big vendor
be interested in something that could be implemented
by a lone hacker in one month??? Where is the revenue???
And of course, a lone hacker first of all cares how long
it would take him to implement some stuff.
Because 'big standards' are driven by ;big guys'
this results in "let us put in a plenty of features",
that results in the situations when some smart Java
developers are now writing some polite articles,
notifying that EJB are , actually, you know ... ,
not for everyting ... ( so is XML ... for example,
why do people think that they need SOAP
for everything, when ... sometimes ... XML-RPC
works just fine? but shhh... that's a secret ...
And why do I need Oracle when MySQL ...
nevermind ... )
</changing context>
Conclusion.
I think we should just take the world as it is
and get XQuery ( with Updates ) out of the
door ASAP and then 'fix' it later.
Sounds terrible, yeah? But I think that from the
bigger picture, all the things that are currently 'bad'
about XQuery are really minor, comparing it to the
fact that XQuery *does not exist*. ( No updates?
This is not a SQL, sorry ).
XQuery with updates, but with messy types,
minor craziness with non-xml-ish syntax e t.c. ?
Just fine. Nobody's perfect.
Somebody would wrap a "MySQL" version out of
that "XQuery" and the 'parallel progress' would start.
Anyway it will take years 'to design the ideal XQuery'.
Not to say 'to implement it' . Again - just look at
SQL after all those years. They will design their
'ideal SQL' forever. Same is with C++. After
creator of STL has changed his profession,
it would take years to 'replace' him. C++
would continue it's progress for a while
and it's 'ideal standrd' is still not supported
by all the compilers.
It is time to start the SQL for XML ball rolling.
1. XML needs it's SQL - ASAP,
2. Nothing comes as close as XQuery ( with updates ) and
3. No matter how long they will sit on XQuery - they
would not make it 'ideal', that's not possible.
Does it make sense?
Rgds.Paul.
> THINGS TO DO IF I BECOME AN EVIL OVERLORD #35
> I will not grow a goatee. In the old days they made you look diabolic. Now
> they just make you look like a disaffected member of Generation X.
IF I BECOME AN EVIL OVERLORD, I'd not build on a
proprietary language until it becomes 10 years old.
Proprietary languages are for crazy geeks. Works all
the time.
|
