XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] "Introducing MicroXML, Part 1: Explore the basic principles of MicroXML"

>>> <extref docno="CTA 50-970" linktype="message" href="CTA 
>>> 50-970 is not included in this document set." color="green" 
>>> popup="1" />
>>> 
>>> Note the linktype and the content of the href which of 
>>> course, isn't an html href but hey, who cares?  :)

>>I don't know where the example comes from, but it goes to my
>>point exactly.  The semantics of that markup is too important
>>to be left out for re-invention by everyone.  It needs to be
>>nailed down with 10-ton bolts!!!!

It comes from a military standard for US Army technical manuals.  The
earlier example using processing instructions comes from a US Army
application, IADS.  And it is still working but mostly because a) it
does its job and b) the US Army owns it, develops it and uses it.  

IADS predates web browsers but already used style sheets, hyperlinking,
etc.  It has what you are describing:  a fixed vocabulary.   In fact,
#FIXED attributes from SGML were an early way to annotate this sort of
thing.  It was in fact, a DTD-less SGML browser.   

IOW, there are markup hypermedia browsers (at least one still standing)
that do exactly what you are describing.  They interleave a fixed
application language into ANY markup including ones that already have
their own semantics for links.   You may want to note that what xml:base
does was done with entity declarations once upon a time before it became
necessary to reinvent them.   People such as me have jobs because like
COBOL programmers, we know how those work (meaning I can read a DTD,
edit in Notepad++ and program so I replace four slots/persons.  Cheap!).

>>That's exactly the problem.  Build it into the language, problem 
>>disappears! Well ok, there may be other problems. 

Well, build it into a separate language and interleave it into the rest
but we're quibbling syntax and legal/contract definitions on that one.
Would you believe me if I told you all of this was discussed endlessly a
decade and a half ago?  HTML had the upper hand in that even though it
had a crummy browser, it was free and it worked for the trivial tasks.
Then with mountains of money and publicity, it became the kudzu of the
information age.  Now it takes its final evolutionary form as HTML5:  it
owns the parse.

And it will die rather more quickly than anyone suspects, but that is a
prediction yet to be realized.
 
>>XML may live on for 1000 or more years, if we make it.
>>How many times can that markup be reinvented?  And each time it
>>gets reinvented is one more reason to not use XML.

It won't exactly get reinvented. Mauled and rebranded is more likely.  I
believe, and John can correct me, MicroXML is a JSON competitor because
it turns out XML is not the best solution to the problem it was touted
to solve: bits on the wire.  On the other hand, let's say Microsoft
makes noise with its Javascript patent, then JSON doesn't look too
healthy and that is precisely why markup if not XML was invented and why
keeping it free of application layers is A Good Thing.

Notice that the markup examples I gave above come from standards that
predate the web by almost a decade.  The DTD used for that is huge and
bulky.  Not important except to note that Internet Time and
Inevitability proved to be yet another myth.   All technologies that get
widespread uptake develop like a wildfire until the uptake reaches some
point of distribution and then switching costs take over.   That is your
main challenge in this proposal.  Where the investments are fairly
large, so are the switching costs.  

That is one reason I have a job.  :)  They can't afford to move on.

>>I'm on board with XSL! Why do you say was/?

Some noises that the XSL-FO part of it may be deprecated as solutions
converge around CSS on the web.   That will be a problem for the world I
work in that makes heavy use of XSL-FO with PDF.  On the other hand, it
is a tooling problem and we simply buy new tools, we don't sell them.

>>Wow.  Still, can you imagine what the impact of this would be on
putting
>>hypermedia affordances in the XML namespace?

I certainly can.   Lawyers get a lot richer.

len


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


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

Copyright 1993-2007 XML.org. This site is hosted by OASIS