Interesting. In Navy design this term is complimentary and intentional, can indicate that something works in all known cases and does not fail even in novel worst-case conditions. Rephrased: if something is not “over-engineered”, or engineered
with deliberate margins of capability, then it is likely to break unexpectedly under unforeseen stress.
Given the looong evolution of XML (building on prior work with SGML etc.) one might expect that it is perhaps unavoidable that some long-ago-important functionality might be less important now, especially when follow-on work provides a
superset of capability (e.g. Schema expressive power compared to DTDs). Complexity causes friction, elegance preferred, not always possible given many disparate tradeoffs involved. Thorough implementation is difficult but it is also interesting that everyone
doesn’t have to use everything.
If the greatest challenges are repeatability and scalability, which indeed keep growing without apparent bound, then it seems that many aspects of XML might be considered successfully over-engineered. (And please keep namespaces on the
list of essential features since they opened the door to composability and even Semantic Web scalability.)
Everyone has different use cases and priority preferences, YMMV of course. Still it seems like everyone knows a heckuva lot more about data models and achieving burly requirements now than then, our horizons keep getting vaster. Thanks
XML! 8)
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman@nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
Also: unparsed entities, notations.
By over-engineered I mean that it has more functionality than most applications require.
Things like DTDs, namespaces, processing instructions, which add substantial complexity to applications and APIs whether you use them or not.
Mirriam-Webster definition:
overengineer: to engineer (something, such as a product) to have more functions, capabilities, etc. than are necessary or desirable
Michael Kay
Saxonica
> On 14 Sep 2021, at 23:49, Roger L Costello <costello@mitre.org> wrote:
>
> 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
>
_______________________________________________________________________
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
