Re: [xml-dev] What are the design goals of your (XML) language?

[Peter Hunsberger <peter.hunsberger@gmail.com>]

I've got a bit more time to expand now then I did earlier, but then I'll be out of here for the holidays... :-)

I like Roger's #2 and his #4.  I've rarely, if ever, seen situations where #1 applies.  #3 is mostly trivial if it's needed. For the stuff I've done it's almost always JSON inside the firewall and I have access to all the endpoints.  We did recently do a API that supported both XML and JSON but it was for semi-public use.  The times I use XML are when exchanging data with known external partners and there things it brings to the table such as WS-security or WS-Encryption.  However, I use pretty much the same design principles whether the format is XML or JSON.... #5 ? Meh, ok...  #6 Sure, there are lots of standards for lots of things that might apply.

None of that implies I have enough of a grammar or any real semantics (other than a verb or two and a response) around the exchange.  So I have a hard time calling any of that a language or elevating any of it to special status beyond saying it's a structured data exchange.  A known structure does not make a language.  In particular, a language seems to imply I can compose individual particles of the exchange in multiple ways (?), and generally that's the exact opposite of what I want to do for what we're discussing here.

On Wed Dec 24 2014 at 12:04:19 PM Toby Considine <Toby.Considine@gmail.com> wrote:

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

---

Toby Considine TC9, Inc. Toby.Considine@gmail.com Phone: (919)619-2104 http://www.tc9.com

Chair, OASIS OBIX Technical Committee Chair, OASIS WS-Calendar Technical Committee Editor, OASIS Energy Market Information Exchange (EMIX) Editor, OASIS Energy Interoperation blog: http://www.NewDaedalus.com

 

 

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