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: James Clark: XML versus the Web

 

Several proposals have been made here to integrate a variety of fundamental XML standards. 

Most take an approach of jamming some subset of a disparate variety of standards into a common structure that maintains all their idiosyncrasies and inconsistencies.  This has the advantage of maintaining functionality.  And with an appropriately large and multi-focused committee, all the animals could be brought into an even more unmanageable zoo. 

An alternative approach is to abstract from competing specifications and generalize their essential substance.  This can provide simpler and more flexible foundations with which to rebuild higher level concepts.   With such foundations, compatibility with existing name spaces can be maintained but deprecated.

Syntax simplification is not too difficult; semantic simplification is somewhat tougher.

Among these fundamental concepts for language foundations are :

·         Data Types – with nesting, inheritance, extension, constraints and executable methods

·         Data Attributes – especially extended specifications for metadata, storage, communication, presentation, dynamics, etc.

·         Data structures – atoms, lists, hierarchies, networks

·         Expressions – arithmetic, logical, selection, iteration, path, set, query, etc. - with basic and extendible types.

·         Parameters & Templates – allowing adaptation through substitution and selection

·         Modules – collections of coherent semantic elements that can be referenced, included, extended and transformed

·         References – names, pointers, spaces, and paths defined among them   

·         Navigation – exercise of actions along a path

·         Dynamics – events, actions, commands, routers, controllers

The second step follows from the observation that XML is no longer just a markup language, but a powerful tool for model specification, especially those for application frameworks.   An application of these fundamentals, along with similar abstractions, can be used to create presentation models, data models, control models, and communication models.

In summary, from this person’s view, for XML to move forward efficiently and effectively there are three issues -architecture, architecture, architecture.  This stands in sharp contrast from the biases of particular functionality which, from comments on this site, seems to be the root of much evil.

A preliminary set of notes for such an approach is available.

 

------------------------------------------------------------------------------------

 
In a message dated 11/30/2010 10:37:55 P.M. Eastern Standard Time, kurt.cagle@gmail.com writes:
BTW, I'd also agree with Dave Pawson's point here. Maybe it's time to reinvent the wheel with an SXML. We know what worked and what didn't. We still have a fundamental disconnect between XML and Javascript that needs to be addressed, and attempting to do it within the rubric and process of XML looks to be a non-starter.

Some areas that I'd like to see -

  • Creating a unified XML/JSON layer, including agreed upon serializations and working to extend both XML and JSON to be fully transferable.
  • Creating a consistent mechanism for the depiction of both closed ontologies (XML) and open ontologies (RDF/OWL).
  • Creating a consistent path/query layer between the syntactic (XQuery) and the semantic (SPARQL)
  • Working with ECMA and the browser and mobile vendors to provide a universal first class SXML representation.
  • A rethinking of distributed linking systems, especially in light of the emergence of RESTful architectures
These are big areas. They'll require that people check in preconceived notions at the door, and they will require champions that will be willing to both put in the effort to be the reference implementors and to defend the specifications from being co-opted by a given vendor.

Kurt Cagle
XML Architect
Lockheed / US National Archives ERA Project



On Tue, Nov 30, 2010 at 10:07 PM, Kurt Cagle <kurt.cagle@gmail.com> wrote:
+2 on DOM

DOM was necessary at the time - you needed a way for external languages to have low level access to XML in order to create tools (such as XPath, XQuery, E4X, etc.) that provided higher level accessibility. The problem was that rather than build XPath or E4X like layers into the browsers, the browser implementers took the DOM spec as the baseline for working with XML, and it took years for any kind of advanced technology to work its way into even a few of the systems (and that often badly). Trying to invoke an XPath statement and do anything useful in Mozilla is hideously painful, even though it would have taken remarkably little effort to make it more usable. E4X (or at a very minimum the creation of XML objects as transparent entities that can be queried via a path language) would have gone a long way to solving that, but there was very little push to get behind it within the W3C, because it was seen as an ECMAScript issue. 

About namespaces - people moan and complain about namespaces, but the biggest problem with them overall was that there were two schools of thought with regard to namespaces within the XML community. The first saw namespaces as a way of applying a class-like semantic to a closed but potentially mixed ontology; this is actually most evident in languages such as XQuery where you have modules that contain functions, which provides an (rough) analog to classes and methods within an OOP environment. The second saw namespaces as a way of identifying authorities, and I believe this is where namespaces largely failed. Anyone who has pored through NIEM or XBRL records understands how confusing such authority layers can be, even by people who otherwise understand the specifications themselves. We've had discussions on this particular forum before about alternatives to namespaces (with some remarkably good ideas being proposed) but rather than actually pushing the changes into some kind of action in most cases these ideas ended up becoming simple gripe sessions.

Which to me points to the bigger problem - process. AJAX came about because a lot of people threw a lot of ideas around, kept the ones that worked, and dropped the ones that didn't. XML on the other hand established apriori specifications through long and involved processes, typically with comparatively little input from the developer community, and often shooting for broad generalized solutions rather than creating things from scratch and then seeing how they could fit into the XML community overall. Significantly, if you look at the most important "standards" in the W3C canon, the ones that had the biggest staying power usually were produced by one person and then "smoothed out". XPath (James Clark), XSLT 1 (James Clark) and 2 (Michael Kay) falls into that category, as does RNG (James Clark again), Schematron (Rick Jelliffe), XProc (Norm Walsh), XForms (Mark Birbeck and Micah Dubinko), XQuery (Michael Kay), RDFa (Michael Birbeck) and the like. That's not to say that other people didn't contribute significantly to those specs, but it was usually the reference implementer that was defining the characteristics of the specification in the first place.

Look at the specs that people typically complain most heavily about - XSD, Namespaces, SOAP and the WSDL stack, SVG (good idea, but one that succumbed quickly to corporate dominance), XML-RDF, as well as some downright obscure ones like SML (the Services Markup Language), and of course, the brilliantly failed XHTML/WICD concepts, which got bulldozed out of existence by Ian Hixon who recognized that modular XHTML was a good case of XML jumping the shark. All of these were specs that came either came into existence or were quickly taken over by large committees representing corporations with strong vested interests, and with no single champions strong enough to fend off those interests in the name of communal standardization. They became catch-alls for a couple of key corporate players with strong agendas (SVG and Adobe is a prime example) that were looking at creating a "specification" that they would have a strong lead in upon completion. SVG is finally gaining traction universally, and curiously enough, most of that traction has come about in the non-animating portion, because that represented what was really needed in most cases.

I think the danger that we face at this juncture is throwing out the good with the bad. XML has gained adoption not because of the XML standards community. It gained adoption because it filled a very definite niche - document-centric structures - quite well, and over time more and more "data" is being represented this way because data is becoming more robust and document-like. That's not going to go away because the browser community (which I see as becoming a decreasingly important part of the overall equation as mobile devices become the norm) has decided that everyone needs to be AJAX developers. It does, however, mean that the XML standards community needs to understand that it has to reach out and recognize that the infoset can have multiple serializations, that not all those serializations are going to involve angle brackets, and that collections of content ultimately will end up becoming more important than individual documents. 

Kurt Cagle
XML Architect
Lockheed / US National Archives ERA Project



On Tue, Nov 30, 2010 at 8:21 PM, Liam R E Quin <liam@w3.org> wrote:
On Tue, 2010-11-30 at 19:59 -0500, Elliotte Rusty Harold wrote:
> On Tue, Nov 30, 2010 at 6:47 PM, Amelia A Lewis <amyzing@talsever.com> wrote:
>
> > I'm increasingly of the opinion that XML "jumped the shark" with the
> > XML Namespaces specification.
>
> Namespaces was at least the nose of the shark. I think we really
> should have insisted that prefixes not be able to be bound to more
> than one URI in the same document.

There are a lot of problems with the namespace spec. I don't think that
particular restriction would be helpful, because it would complicate
reuse of document fragments. But, lack of consensus at the time
reflected lack of implementation experience -- namespaces should have
been put on hold for a couple of years at least.

> Schemas are bad, but ignorable.
I think XSD has some OK parts, and, like namespaces, meets some real
needs... while causing lots of problems of its own.

>
> I remain convinced, though, that the single biggest mistake was DOM.

+1 here, totally agree.

Liam


--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php





[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