We are a very disparate group here, coming from many different
backgrounds, many with a very particular focus.
Consensus, as you say, is difficult and indeed
impossible. Consensus in a variety of smaller areas seems feasible.
For a more comprehensive approach, there will need to evolve some decision
process with something like a "chief architect".
One of the worst dangers here is that support from a commercial
supplier of browsers will be necessary, and they will be motivated to run away
with early and incomplete approaches.
Maybe the exercise can be organized usefully
though.
Organization is fundamental and I'm sure will, and certainly
must, evolve in unforeseeable ways. The following illustrates one
possibility for a general framework.
As a starting point there seems to be two fundamentally
different camps; both useful, but in quite different ways, but needing
separate areas of development:
* Those who advocate incremental, evolutionary and reasonably
compatible change in a variety of areas.
Here what is needed is a series of topics that can
be easily created and evolved towards some sort of formal recommendation.
Here only partial consensus is needed; e.g., I suspect two, hopefully
complementary, approaches for comments will evolve.
* Those who advocate radical, revolutionary change, albeit with
compatibility considerations.
Here there needs to an outline of topics to be
developed.
The latter is more difficult. Separate topics for
objectives, requirements, specifications, design principles, design issues,
document guidelines etc. is an obvious starting point. In the long
run, these can evolve from discussion entries to an area for formal
resolution and public documentation.
A single outline of separate topics for a unified
and complete specification set is more complicated. In my own notes,
I find it difficult to focus on one topic without referring to many
others. For instance, concepts of modularity, inheritance, referencing in
general, links, path expressions, queries, (replacing) namespaces, packages,
templates, etc. all become bound together.
I would not be surprised to see several outlines of
topics evolving, each attempting to be complete and comprehensive from a
different perspective. These should be allowed to evolve freely.
This would then be complemented by a rigorous integration effort to tie the
best of all the topics into a coherent whole.
This is only one possibility for part of the website, but it can
combine the best of two development approaches; i.e., a wide variety of
inputs with integration by a small set of individuals.
In a message dated 12/5/2010 7:57:01 A.M. Eastern Standard
Time, elharo@i... writes:
I suspect that's a little premature. It's not enough to
agree that
there should be a next XML, if we don't have some plausible idea
of
what that means. So far what I'm gathering is that there's
not
anything approaching consensus on what the next XML should be,
if
anything. If what we have is 20 different folks pulling in
20
different directions, then this is pointless (though it's
interesting
to find that out). So far, we have fundamental disagreements
on:
1. Remove some syntax or support all existing syntax
2. Add new
syntax or don't add new syntax.
3. Add new semantics or don't add new
semantics.
4. Schema based or schema agnostic.
5. Graph based or tree
based
That's 2^5 possible combinations, or 32 separate positions. More
may
be forthcoming, and I may have missed one or two. If there's just
0-2
folks falling in each camp, then I doubt we can do much. Personally
I
was aiming for yes on 1 and 3, and no on 2, 4, and 5 (though some
of
the discussion here is suggesting that 3 alone might be preferable)
.
I was hoping a core group might coalesce that agreed on
the
fundamentals. Or perhaps a couple of core groups that would
do
different things and let the market decide. I'd love to see what
a
graph-based markup language looked like, for example, though I
suspect
that's really something de novo and not a new version of
XML.
However I do not wish to repeat the W3C schema or WS-FOO
experiences
where every party throws every personal feature into the hat
and
produces an incoherent mess. Instead I'd like to repeat the XML
1.0
and XSLT 1.0 experiences where a small group of interested folks
with
a shared vision produces something clear that they can present to
the
world. This will not be presented as a de jure standard that must
be
adopted, but rather as, "Here's something cool that we worked on.
Let
us know if you like it. Use it if it seems helpful."
Anyway,
it's early yet. Not even the work week for most of us. Let's
see what
Monday brings.
--
Elliotte Rusty
Harold
elharo@i...
_______________________________________________________________________
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@l...
subscribe:
xml-dev-subscribe@l...
List archive:
http://lists.xml.org/archives/xml-dev/
List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php
Cart
