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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Note from the Troll

[ 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!


A city is like a large, complex, rabbit
 - ARP


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS