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] Re: Native XML Interfaces

Evolution vs. Revolution.

I've been spending a lot of time in the RDF space in the last couple of years - once I got past the blinkers about RDF expressed in XML. Is RDF the next big thing? Probably/possibly/maybe not, but curiously it is now solving many of the big use cases that had seemed insurmountable when expressing information in hierarchies rather than graphs.

Yet I think the relevant issue here is that I do not see RDF and XML as being independent, but rather part of a continuum of convenience. Hierarchies ARE immensely useful for a great number of things, but until you have XML in a database with a lot of other XML do you begin to understand where it has its limitation - not so much a failure on the part of XML but rather a transition from forests or groves of XML to linked resources that fall outside of the applicable domain of XML. That becomes obvious when you look at XBRL, which, had they only waited a few more years, would have been a remarkably good fit for RDF.

These are evolutionary - RDF emerges as a natural use case when the amount of associations in XML become too burdensome to continue managing in XML oriented code. It does not invalidate the XML - indeed, after nearly fifteen years I'm actually finding utility for RDF-XML as XML.

Liam's comments on imperative languages are significant - each language attempts to solve the short comings of the previous, and in the process become incompatible from their parent. They are revolutionary. The declarative languages (and REST, which I'm coming to believe is one of the unifying principle of data science over networks) augment rather than replace their antecedents.

It's funny. I've gotten lazy about learning imperative languages, beyond those parts that seem to focus on the "RESTful bits". Part is fatigue - I just don't have the patience to learn yet another imperative language - but part of it is simply the fact that in focusing on those same RESTful bits, I normally can get by with a language enough for me to do what I personally need because the business logic is no longer in the imperative code - it's in the data layer.

Kurt

Kurt Cagle
Invited Expert, XForms Working Group, W3C
Managing Editor, XMLToday.org
kurt.cagle@gmail.com
443-837-8725



On Fri, May 31, 2013 at 7:45 PM, Liam R E Quin <liam@w3.org> wrote:
On Sat, 2013-06-01 at 01:45 +0000, David Lee wrote:
> This is quite interesting.
> Not pointing fingers just Pontificating from a glass house:)
>
> W3C doesn't want to be in the API world (dont blame them,  #fail #DOM #fail)

That's changed these days, but for sure DOM did a lot of damage to XML.

Standards bodies are not really needed until there are multiple
implementations and a spec is in demand by users. Vendors benefit from
incompatibilities until the users insist on standards.

We did well with XML because there were implementations of SGML, and XML
was originally SGML for the Web. SoftQuad and EBT both had Netscape
plugins to show SGML, but there was little or no interoperability
between them. We each chose a different proprietary subset of SGML.

One problem with inventing things at a standards body is that standards
bodies don't generally have much (or any) budget for promoting specs;
they assume an external market will do that.

JSONIQ is one of the more interesting things happening in the XQuery
space right now; if XProc 2 happens it might also be pretty exciting,
especially if we can get EXI to work with XDM instance streams so you
can distribute pipelines reasonably efficiently, no XML parsing needed.

My own fear is that practical things like "the size of an image in
pixels" are ignored [1] in favour of function currying, forgetting that
the big win spot for XML is people who don't consider themselves
"hard-core programmers". Higher order functions are useful; the ability
to be a back end for Web apps is essential.

Liam

[1] note - some implementations, including zorba, do have functions to
get image size, EXIF and/or IPTC metadata and other information out of
images, but it's not something the WG will pursue.

--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml




[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