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] constructive (was RE: [xml-dev] Markup perspective not cod

[ Lists Home | Date Index | Thread Index ]

Hi Simon

Simon said:
At some point polarization is necessary.  Constantly aiming for
consensus 
and insisting that all conversation lead to consensus is an excellent
way 
to stifle diversity by keeping genuinely conflicting viewpoints from 
surfacing.  There's a lot of nastiness in the XML technologies at this 
point, and I believe the conversation should reflect the technology.

Didier replies:
I agree that the actual state of the XML framework is quite messy and
needs the same spirit and will that XML got at its beginning when it
tried to simplify SGML. Is W3C the right organism for that? I doubt, W3C
is unglued a mechanism that leads toward more complexity. Is Schumpeter
right and do we need "constructive destruction"? maybe the technology
can evolve by starting a new organism. This said, my point is that the
polarization between programmers and XML authors is not leading to
constructive matters, we attack the people not the ideas. We should be
critic constructively the ideas not the people. I do not advocate forced
consensus but good manners and respect toward people.

Simon said:
If there's a genuine conflict - and I believe there are many at this
point 
- I think it's far better to air them (and strongly) than to leave them 
festering.  It may in fact be time for division into smaller groups
where 
consensus is achievable, but I think we need to find out what those
groups 
are before we can find our way into them.

Didier replies:
I agree that different point of views have to be debated. Let's come
back to ideas for a moment. If we want to help the developers using
procedural code, we need to provide them constructs that make sense to
the problems they have to resolve. Here are some requirements:
a) That the infoset is presented not as a collection of elements and
attributes but as "gizmos" (1) having the elements name. To be debated,
do attributes are to be considered as "gizmos'" properties? The goal is
to make possible the process of XML documents with constructs like
account.balance(2), not a bunch of functions just to access the info
that other languages do with few constructs. If I ask people if they
want to pay more than what they are actually spending they will say no
if this is the same product/service they already have for less. It would
be foolish to think that people would spend more. But often in this list
I read messages saying that yes they would spend more. I can just say
that, in the real world, this behavior is not necessary nor useful :-)
So, requirement (a) is not actually fulfilled and this leads to other
solutions not leveraging the actual strength of XML structures (even if
it uses the same syntax).
b) That programmers have access to the different level of information
extracted from an XML document. For the moment, we fulfilled the lowest
levels at the syntaxic level but still do not provide useful tools for
80% of the problems resolved by developers. When developers are using a
Perl, C++ or visual basic program they DO NOT HAVE TO WRITE NOR HAVE TO
USE A PARSER. They are using function, procedures and variables. And the
more popular tools are the ones following the Maupertius principle (3)

Conclusion: people tried to fill the gap. So, can I ask the community to
mind the gap and not polarize but use their brain to listen to the needs
and try to find a good solution. If somebody is thirsty and lost in the
desert I can either
a) help him/her find water
b) give him/her some water
c) deny his/her needs
Actually, I read a lot of messages using strategy (c) instead of trying
to respond to a _concrete_ need. 

The real question is now. What are the _concrete_ alternative solutions
we are proposing to these people. 

(1) I am using the word "gizmo" since some seems to have an alergic
reaction to the word "object" and I do not want to trigger hypothalamic
responses.
(2) From the following structure <account>....some
elements....<balance>200.00$</balance>....some elements....</account>.
The elements content can be, and I said, can be, treated as one the
elements properties. A property that could be either a value and/or a
collection of elements. Off course this leads to a hierarchical
data/"gizmo" structure and thus this construct could be perceived as a
mini hierarchical data base by a procedural/functional programmer. We
previously saw this type of programming in systems like autocad, MS
office, Visio, Etc.. where function/procedure can manipulate a pre-built
structure (ref: Programming by demonstration, The MIT Press (c) 1993 by
Allen Cypher).
(3) Principle of economy. Taking the path of least resistance or said
differently the shortest path - i.e. a geodesic curve in the case of a
curved space and a straight line in the case of a planar space.

Cheers
Didier PH Martin






 

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

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