I think the list pre-supposes that the API-style XML (to distinguish it and mu comments from the document-style XML already discussed in this thread) is that it presupposes a known app.
Often the impetus for defining a formal XML vocabulary is to support business services that are not fully known, nor fully defined at this time. Business services are selected based on how well they deliver the requested service, not on how precisely they implement a pre-existing API. You may start such a definition with several quite incompatible “data formats”, which may be used in quite different message patterns. The challenge in defining such exchanges is not , matching any one of them, but deciding what is essential, what is merely historical, what is overly familiar (and may thereby unnecessarily limit potential service providers, or constrain evolution).
This is what comes to my mind when I read Peter’s comment. He may have still more issues in mind.
If on the other hand, you are simply creating schema to document existing APIs, then (1) and (2) as Roger suggests may be adequate
Tc
"There are seldom good technological solutions to behavioral problems."
-- Ed Crowley
From: Peter Hunsberger [mailto:peter.hunsberger@gmail.com]
Sent: Wednesday, December 24, 2014 12:10 PM
To: Costello, Roger L.; xml-dev@lists.xml.org
Subject: Re: [xml-dev] What are the design goals of your (XML) language?
Although many of your design goals are sensible your primary postulate is untrue for many of the things that people use XML for. A series of name value pairs does not make a language, even when some of those values are other nested name value pairs.
On Wed Dec 24 2014 at 10:06:38 AM Costello, Roger L. <costello@mitre.org> wrote:
Hi Folks,
Before Java was created, the creators of Java came up with a number of goals for the language: it must be hardware and O/S independent, object-oriented, interpreted, and so forth. [1]
I suspect that all successful programming languages began with its creators laying out goals for the language.
When you create a new XML vocabulary, you are creating a new language. Before creating a new XML language, do you first lay out a set of goals for the language?
I suggest the following could be used as a starting point for a set of goals:
1. (Where relevant) There must be an easy on-ramp from the current non-XML data format to the new XML-formatted data. That is, if one understands the current data format, it should be a small step to understand the new XML-formatted data. The new XML language should favor simplicity and transparency over cleverness and complexity.
2. Data dependencies (co-constraints) must be readily expressible under the new XML format. The implementation of the data dependencies must be understandable by Subject Matter Experts and the (Schematron) implementation must execute in an efficient and timely manner.
3. The new XML format must be easily converted to JSON and conversely the JSON must be easily converted to XML.
4. The data formats must be round-trippable:
a. Convert the current data format to the new XML format and then convert the XML back to the current data format. The resulting document must be semantically identical to the starting document.
b. Convert the XML-formatted data to JSON and then convert the JSON back to the XML-formatted data. The resulting XML must be semantically identical to the starting XML.
5. The new XML-formatted data must have a reasonably small memory footprint when compressed.
6. (Where relevant) It must be possible to map the elements used in the new XML-formatted data to the elements used in related XML that other communities use.
What goals would you add to this list?
/Roger
[1] Java goals: cecs.wright.edu/~tkprasad/courses/cs884/java1Goals.ppt
_______________________________________________________________________
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
