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.
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/
|
