Re: Reflecting on a decade of XML: Lesson Learned
In one sentence â an early flurry of unreconciled objectives have missed fundamental simplifications, and, perhaps, the process has mired in details.
So here - a holiday grab bag of comments on objectives and simplifications, including base capabilities for:
Â· separating âwhat isâ specifications from âhow toâ model implementations
Â· foundations for a uniform syntax separate from semantics
Â· separating application data from specification data
Â· separating markup from other data.
It would seem that attempts at a u-XML and at XML standards simplifications need clear statements of objectives in order to decide what features to include or exclude.
If, for u-XML, advantages for users is a primary objective, problems with u-XML include:
Â· If an application is concerned with just text, many would use PDF, Microsoft Word or some other capability.
Â· Secondly, most Web applications need to deal with data that exists in many forms and representations, of which text is a small subset.
Â· Thirdly, most uses of the u-XML data would still require the complexities of other XML based technologies, in particular XHTML and probably XSLT. Thus any objectives of simplicity for application developers are only partially achieved.
If, for u-XML, parsing simplicity is a primary objective, which seems to be mostly what itâs about, then defining a subset for special uses (e.g. limited devices, very large documents) might be useful, but it shouldnât add complications. However, Iâm not sure that parsing simplicity is a major seller.
If simplification of and capabilities for application development(which is what XML and related standards are actually used for) is a basic objective then the following discussion seems relevant.
Simplification can occur basically in two ways â which are not incompatible.
Â· Removing awkward features and complications â which diminishes capability
Â· Generalization and building upon fundamental abstractions â which can greatly enhance capabilities.
Relative to u-XML:
Â· XML is designed to deal for text markup.
Â· For markup, u-XML is a basic simplification.
For specifications, JSON and YAML like approaches are quite different simplifications, but allow for data typing.
Â· From this perspective, âtext markupâ can viewed as a basic type - for which angle brackets, elements and attributes are well suited. (Basic text does not need angle brackets to be escaped.)
This can allow advantages of u-XML and a JSON like language to be combined where useful.
Relative to specifications, SGML heritage is a hindrance. If one accepts that a specification language has fundamental differences from a markup language, then it is probably useful even to start with a new vocabulary (still, with translations for compatibility in mind):
Â· âElementsâ are either data or data types (with Infoset like representations).
Â· âAttributesâ are properties, either:
Â¨ specific properties for a data type, or
Â¨ general properties (presentation, storage, metadata, events) applicable to many data types.
Â· âDocumentsâ are specification streams (e.g. files)
Â· Delimiters are used for nesting, grouping, lists, comments.
Â· Some use of âkey wordsâ is probably appropriate (e.g. inheritance) .
Several simplifications (with admittedly some oversimplification here) seem obvious to begin with:
Basic structure and syntax structure (actual syntax details are another issue) should allow for:
Â· Specification statements consist of:
Â¨ name value | expression â for data content
Â¨ name type specification - for schema and other declarations
Â¨ name reference | reference_expression - for templates
(These statement types can be combined in a single specification file where useful.)
Â· Data types can include properties and behavior, and methods can be implemented in reference libraries.
Â· name(size) and name(index) can be used for arrays of data.
Â· name*, name+, name(minSize, maxSize) can be used in type specifications.
Â· Names can be prefixed with external name scope identifiers ( including resource identifiers, such as URIâs), which are possibly aliased.
Â· Names can be imported (and possibly aliased) from other name scopes with using specifications.
Â· Expressions can include:
Â¨ Data value expressions for arithmetic, comparison and logic expressions.
Â¨ Reference expressions including path names. Path steps can follow any reference value.
Â¨ Type expressions can include structures and also EBNF, along with constraints and defaults.
Choice would be indicated with a bracketed list with â|â.
Ordering, if needed, could be specified with a decorated bracket.
Â· Parameters are values that can be provided in specifications or derived from data content, and allow for tailoring and adaptation of data and specifications.
This includes conditional substitution and evaluation, and use in expansion of templates.
Â· Modules can be used for reference, substitution, inheritance (extension, with polymorphism, restriction, and overrides), and transformations.
Â· Module hierarchies, including:
Â¨ Conceptual models (typically, for standards)
Â¨ Abstract models (typically, for application frameworks)
Â¨ Concrete models (for implementations, typically tailorable).
From this powerful application development capabilities can be created with models for
Â· presentation (ala HTML, OpenDoc, XSLT,etc.)
Â· data structures (RDF, XQuery, etc),
Â· communications (XForms, Apache), and
Â· control( events, actions, SCXML, workflow, etc.) â the âhow toâ knowledge.
From: "Costello, Roger L." <firstname.lastname@example.org>
To: "xml-dev@l..." <xml-dev@l...>
Sent: Mon, December 27, 2010 8:22:37 AM
Subject: Reflecting on a decade of XML: Lesson Learned
In one sentence, what is the single most important lesson that has been learned from using XML over the last decade?
Here's my take:
Tasks of greater complexity may be accomplished
by distilling out and isolating "what is" knowledge
(in contrast with "how to" knowledge) and
expressing "what is" knowledge in a declarative syntax
that can be queried, manipulated, and exchanged by
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: email@example.com
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]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format