I couldn't agree more, Rick.
What I'm seeing at work here is a form of bitter personal disappointment coming from an XML-centric viewpoint expecting the world to bow to XML for each and every information serialization task. And much like in a frustrating love affair, participants take incidental events for guidance, seeing those as contributions to an academic discourse, when in reality the invention of JSON was just an ultra-practical trick based on _javascript_ object literal syntax, eval(), and the utter need for compact _javascript_ code in early-2000 web pages.
SGML is an authoring and delivery format for digital text, no more, no less. Web Service payload serialization using SGML/XML only makes sense with thin browser frontends merely decorating, filtering, or remapping internal to presentation vocabulary, a thing we don't do much anymore, and CSS can do for us in limited forms anyway. XML with XSD also happens to be very useful for highly structured file formats and information exchanges.
But for actual authoring, encoding, and delivering text, SGML is already the Alpha and Omega of markup, bar none. Not only is its value as delivery format demonstrated day-in day-out in billions of web page accesses, it also also has actual solutions for text authoring tasks for everybody, such as being able to interpret plain ASCII text with just newlines and tabs into canonical angle-bracket markup (= XML).
Best Regards, Marcus Am 15.09.2021 um 03:24 schrieb Rick Jelliffe <rjelliffe@allette.com.au>:
Is a Swiss Army knife (SGML) over-engineered compared to a knife and fork (XML)? For the people who need to do complex things, no. For the people who need to do a few simple things, yes.
And are knives and forks over-engineered compared to chopsticks (CSV?)? Does the fact that much of the world gets by with chopsticks "prove" that knives and forks are over-engineered? In the future, when we all use sporks, would that prove that knives and forks were not up to the job, or just that we had all fallen prey to honey-lipped spork salesmen?
To me, these are not remotely objective questions: all they do is provide a MacGuffin for our individual personality traits. A person who likes to minimise the chance of their peas falling off the plate will choose a knife and fork, and consider themselves smart; a more visionary person may say the answer is to create a specialized fork-shovel, and be frustrated that it isnt obvious to all; a more root-cause thinker may say that the real problem is serving peas on distant plates when they should be in small cups we can pour into our mouths; another may think that the problem is a non-problem if the cook just made chopstick-friendly pea patties.
But what makes little sense, to me, is to call something "over-engineered" for a scenario it was not engineered for in the first place. "Too complicated for this" or "not powerful enough for that" and so on are adequate terms. A thing can be called "engineered" if it came about through certain disciplined and lesson-learning human activities, applying science and rigour to a technical goal: it is not a property of the thing but its history, how it was made. Few things can be considered "over engineered", by that definition.
Rick Michael Kay wrote:
> Given that XML is over-engineered for many of the tasks
> that people were using it for, other standards better suited
> to a subset of those tasks were always going to emerge.
What does that mean, "over-engineered"? Does it mean, "too restrictive"? For example, XML does not allow two attributes with the same name to occur on an element. XML requires every start tag to have a matching end tag. Those are kind of restrictive. Is that what you mean by over-engineered? Or do you mean something else?
/Roger
_______________________________________________________________________
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
|
