[
Lists Home |
Date Index |
Thread Index
]
On Sunday 27 October 2002 16:15, Amelia A Lewis wrote:
> > I need to write the follow on to this piece but it will focus on point
> > 6 above plus the assertion that XML fails as both a markup language
> > (markup shouldn't require well-formedness) and as a serialization
>
> *ABSOLUTELY* disagreed.
>
> Well-formedness is the thing that makes XML worthwhile. SGML, intended
> for writing in text editors, has all sorts of cute little tricks called
> "markup minimization". You can end a tag with </>. If SGML had
> primitive types for elements, you'd see minimization like <price/2.99/.
> And other Stupid Tag Minimization Tricks. These are great for typing,
> until you reach the point in the document that looks like this:
> </></></></></>
> Hope you don't have to extend one of those sections. Whatever they
> are. Still worse if you have full minimization, where the end tag is
> merely implied. Does this element imply the end of the last three open
> tags? Or just of the last two?
>
> Well-formedness removes ambiguity. It does so at the expense of
> terseness. It's a good choice for a markup language. It's a poor
> choice for a data exchange format, where all the data is in very tiny
> chunks, and the ambiguity does not arise.
Methinks the argument is more that you should be allowed to have:
"This is <italic>italic <bold>bold-italic</italic> bold</bold> text"
...sorta stuff than all that shorthand that meant a parser HAD to have access
to a DTD to be able to know what was closing what :-/
> I was a grunt programmer at some of those companies. Speaking from the
> trenches (RPC, DCOM, CORBA), I don't think those models work. In fact,
> I think that they're seriously flawed by adopting Sun's marketing
> slogan. The network is not a computer.
This is my area of ranting...
People say RPC/DCOM/CORBA/etc try to 'hide the network' and make your remote
logic appear to be just there. They say this is a bad thing because the
network is unreliable and loosely coupled in ways that code in an address
space isn't.
But that argument's not really valid. For a start an in-memory call might be
to a dynamic library that's not currently paged into memory - in fact, the
shared library file might have been deleted since it was linked in or the
stack overflowed! Ok, most current systems will kill the processes if either
of these events occur, but they could just throw a GruesomeSystemException to
give the code a chance to apologise to the user. Indeed, the equivalent of a
404 in following a loosely linked function pointer in a POSIX execution
environment is a trappable SEGV signal!
Programming languages that have exceptions don't need to hide the network
when doing RPC. The RPC calls can just throw an extra RemoteException if
there's a networking problem, and bob's your uncle; we're exposing the
potential unreliability of the network, and nobody every said that any method
call has to be particularly fast anyway so we've nothing to hide in the
latency department!
Also, just as we have mechanisms to make shared libraries and DLLs not break
dependent clients when they change (not that people always use them, mind...)
RPC protocols tend to allow one to add new versions of the interface to the
server while still supporting clients using the old interface; if you've just
added some extra methods then you can use the same code for the old and new
methods, but if you've changed a method then you provide an implementation
for incoming requests to the old method that does whatever is needed to map
it to the new method.
And as for the REST argument that 'there are only a few methods, GET and POST
and others'... I think it's wrong to say that GET and POST are methods in the
same sense that getName () and getAge () are; in HTTP you would do GETs on
seperate URLs for the name and the age, or GET a single URL that returns both
name and age. In no way has GET replaced getName and getAge. HTTP's GET and
POST and so on correspond more to an RPC protocol's' INVOKE' operation than
to the application-level getName () and getAge ().
> Alaric doesn't agree, 'cause he doesn't see value in text-only formats.
They have a few uses still, but I see textual formats as a thing from the
*past* days of punched cards that, we should be migrating away from :-)
I want a punched card read/writer, though. I like retro hardware.
> Amy!
ABS
--
A city is like a large, complex, rabbit
- ARP
|
