Re: [xml-dev] Most XML vocabularies are too large and inevitablyhave lot

[cbullard@hiwaay.net]

Ok.

For production shops that use the DTD to constrain meatspace, it means  
creating alternative tighter versions per contract.  This puts the  
onus squarely on the producer to ensure the markup meets the  
consumer's requirements.   Higher fidelity requirements tightens  
coupling and shrinks the surface area of the available consumers.   
Removing uncertainty enhances quality for a smaller set of potential  
customers but a bird in the hand, etc.

However it leaves the problem of XSL contributions to post-validation  
products that are undectable without testing.   The idea of generous  
acceptance of liberally provided information falls apart with high  
probability.

This why when someone refers to web work as "publishing" I giggle.  It  
is broadcasting.

len


Quoting Kurt Cagle <kurt.cagle@gmail.com>:

> 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.
>
> Kurt Cagle
> Managing Editor, XMLToday.org
> kurt.cagle@gmail.com
> 443-837-8725
>
>
>
>
> 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
>>
>>
>