OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] syntax, model

[ Lists Home | Date Index | Thread Index ]


Danny Ayers wrote:
>>mc@xegesis.org (Mike Champion) writes:
>>
>>>The best is the enemy of the good.
>>
>>In the case of DOM, the twisted semi-generic mess was the enemy of the
>>useful.
>>
>>Nor does that epigram push strongly against my conclusion, which
>>includes a range - the further you get from the syntax, the deeper the
>>poison runs.
> 
> 
> The epigram's ok as far as it goes, but I disagree with the poison tasting.
> The cases mentioned (XPath etc) do suggest that distance from syntax is
> proportional to toxicity, *but* all these cases have one-size-fits-all
> semantics. Closer to the syntax (as in DOM), the model and a particular
> (abstract) syntax are tightly bound, even equivalent.
> 
> But meaningful communication depends on some level of shared semantics. So
> ideally we should perhaps be looking at looser coupling between syntax and
> semantics. It shouldn't be necessary to buy into a whole package of meaning
> (a company's invoice structure) but be able to map selectively between local
> models in a global environment, choosing the syntax that best fits. The use
> of purpose-specific XML languages has an implicit alignment to the
> single-model approach, and that I think is where the problem lies. The model
> is the baby, the syntax merely the bathwater.
> 
> I personally think using an uber-framework about syntax and
> business-specific models is the only way around this, and the RDF/OWL
> approach seems a very good candidate.

John Sowa just posted this on the Conceptual Graph list -

http://mars.virtual-earth.de/pipermail/cg/2003q4/005246.html

In it he refers to another article, and says in part -

"I like his examples of companies that have no definition -- or
sometimes, too many definitions -- of fundamental terms, such as
"customer" and "product".  Trying to define a "standard ontology"
that would state official definitions of such terms would not help.
On the contrary, it might make matters worse:

  1. If there were an official definition, some programmer or
     database administrator might be tempted to implement it.

  2. As a result, every application that assumed a different
     definition would fail.

  3. In an ideal world, programs would stop with an error message
     that explained that there was an incompatible definition of
     some critical term.

  4. In the real world, most programs would continue to run, but
     they would generate erroneous data that might cause important
     customers or products to be ignored or treated incorrectly.

  5. Even if all offending definitions could be found and
     eliminated, programmers might be forced to implement
     "work-arounds" consisting of highly insecure and illegal
     code to handle customers and products that fall outside
     the official definitions. "

Comments, Danny?

Cheers,

Tom P






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS