Re: [xml-dev] Most XML vocabularies are too large and inevitably havelot

A model is, fundamentally, an abstraction - the removing of extraneous information from an assertion of "reality" in order to create an analog to a given entity or process that is more tractable to understanding or representation. You are giving up fidelity for simplicity with any model, and the more you simplify, the more tractable the model becomes, but at the cost of loss of fidelity when the model is scaled to the broader domain. In physics, for instance, you teach beginning physics students the world of perfect motion - frictionless surfaces, infinitesimally short impulses, perfectly elastic collisions - because these things are easier to understand, yet after a relatively short period of time most students realize that the world that they are modeling does not in fact have much real correlation with their observed reality. Then you slowly introduce friction (first as a linear differential equation then later as a very non-linear one), you introduce inelastic collisions, relativistic and quantum effects. You are adding more "terms" here, but at the cost of greater complexity, non-linearity, fractals and even emergent behaviors, and often at the cost of going from certainty to great uncertainty about the role of specific characteristics in the model

The same holds true in the ontological space. Ontologies are models that represent a consensus of perceived need, but these models are by their very nature incomplete, because the perceived needs of a model may vary considerably from one individual to the next (especially once constraints and interactions with other models is also taken into account). The best models are those that describe the Venn intersection of common interests vary well, that describe the less intersected domains of interest moderately well via abstraction, and provides an effective mechanism for both delineation of non-interests and a mechanism for extending peripheral interests, albeit with far less fidelity. Verbosity really doesn't enter into it - the description of an aircraft avionics systems may have tens of thousands of precise terms, but still may be inadequate to describe the domain, while other schemas may have a dozen or less terms but be generally quite descriptive, perhaps overly so. The question is whether the domain being modeled is expressing those parts it needs modeled most more accurately than it is those that represent interstitial connections and external processes or objects, and whether this description is adequate to the task at hand.

On Sun, Dec 18, 2011 at 4:06 PM, Len Bullard <cbullard@hiwaay.net> wrote:

Not sure about the case for schema or instances of it, but with DTDs as the
number of cases a single DTD is made to support, the weaker the support
becomes. �This is a problem for XML where DTDs validate one end of a
production and XSL performs post-validation substitutions. �The DTD cannot
be written tightly enough to ensure the XSL consumes the right tags and
outputs the correct XSL-FO, for example.

We really do lose a lot of time and money to the inability or unwillingness
of providers to create, maintain and provide multiple tight definitions over
singular loose ones.

len

-----Original Message-----
From: Michael Kay [mailto:mike@saxonica.com]
Sent: Sunday, December 18, 2011 2:17 PM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Most XML vocabularies are too large and inevitably
have lots of "holes"

Indeed, most standards are too large.

XML is too large. Attributes are unnecessary, mixed content is
unnecessary, namespaces are unnecessary: without these unnecessary
concepts, XSD and many other things would have been much simpler.

XSD is certainly too large.

Many application-level standards such as FpML and HL7 are too large.

But stating that something is too large doesn't help to make it smaller.
(There was a W3C workshop on XSD where everyone agreed it was too big
but no-one could agree which bits were unnecessary.) There's a basic
problem that the more people you involve in a design, the larger and
more complex it becomes. At the extreme, this leads to the failure of
billion-dollar IT projects. This is a sociological problem in the way
systems are created. But recognizing the fact doesn't make it go away.

Looking to mathematics for inspiration isn't particularly constructive,
because IT systems have to fit into the real world, and the real world
itself suffers from excess complexity; a specification can also fail
because it oversimplifies, or because it imposes too high a level of
abstraction.

Michael Kay

_______________________________________________________________________

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