[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Generic XML Tag Closer </> (GXTC)
- From: David Lyon <david.lyon@preisshare.net>
- To: xml-dev@lists.xml.org
- Date: Thu, 24 Aug 2006 01:28:18 +1000
On Wed, 2006-08-23 at 09:49 +0100, Richard Tobin wrote:
> In article <1156317071.18946.246.camel@localhost.localdomain> you write:
lol..
> >> Any idiot can make up a better markup language than XML, and many idiots
> >> in fact do so.
>
> >I think this is a very condescending statement about the people like
> >David Megginson who put XML together. Saying that it only takes an idiot
> >to do better. You obviously have no understanding of the skills,
> >hardships, determination and sacrifices of any person who tries to
> >advance the common knowledge.
>
> You have completely misunderstood Rick's message.
Nah.. I think I understood it.
>
> For any given purpose, XML is unlikely to be the ideal markup language.
> It would often be easier to write a better markup language for that
> particular purpose.
It isn't easy. No matter how easy on the surface it may seem.
You have to have the staying power to stick with it for years if not
decades to see it through.
> The point is that you need to consider whether the advantages of your
> special-purpose language outweigh the advantages of using a
> standardized language such as XML.
Well, the special purpose of my markup style is to safely and
efficiently transmit business data with little ambiguity at both send
and receive points. Especially in the context of being useable with
sql-92 databases.
ie the following line can be losslessly loaded into an SQL database with
it's CREATE statement automatically determined : <msg>
stringfield&="stringdata" logicalfield?=True numberfield#=18
currencyfield$=25 datefield@=2006-10-10</msg>
For me, I find pure and simplistic XML to be lossy. As in you lose
information about data-types because it isn't recorded on the way in.
And so it becomes almost impossible to recover it at the receiving end.
That deficiency then generates quite a large amount of baggage right
across a production system that can almost outweigh the weight of the
core functionality.
But if bulk isn't a worry, then it won't worry you.
Most XML systems are tightly coupled, so it isn't an issue.
But my markup enhancements are oriented at more loosely coupled systems.
> If you use XML your markup will be
> a bit uglier, probably more verbose, but you won't have to design it
> or write a parser or serializer for it. And quite likely some of the
> things you want to do with it will be doable with existing generic
> tools like XSLT.
True - but there comes a point where having a good markup just
disappears like the foundations in a house. The customer never sees it.
All they see is that they can get a system that isn't as monolithic as a
traditional tightly-coupled-xml system and can more easily adapted to
use more-or-less fields with greater ease.
Anyway, you are right, there are a lot of good tools like XLST and so
forth and I have a healthy respect for all the effort that has gone into
developing it all.
> In the end you may decide that the advantages of a
> special-purpose language outweigh the disadvantages, but you should at
> least consider the question.
It's like having your own 100 acres and being able to build whatever
sort of racetrack you want and drive whatever sort of vehicle you want
around on it at any speed in any sideways (or spinning) direction you
wish.
The only disadvantage is that if you go into town one day somebody will
drive past and shout out of their window "You Idiot".
to which the only thing you can answer is "Whatever.."
> Now of course most of the people who unnecessarily invent new markup
> languages aren't "idiots". But you're not meant to treat pithy
> comments that literally.
maybe Rick was feeling bored/lonely and just wanted to stir up some
conversation ..... It's what I have come to expect from my local W3C
official... but I'm sure they are more professional in other
countries.... just not here...
Regards
David
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]