[
Lists Home |
Date Index |
Thread Index
]
I assert the future is inventable. Others have said
as much. So the committee does choose and must. Results
vary. Choose wisely.
Choosing requires strategies and tactics and these
have to conform to practiced recognized behaviors.
This outs another permathread: simplicity, expedience,
and time to market/release/publication/final spec form.
The usual suspects of interedependent polarities:
o It is desirable to specify the exact problem and
solve only that (tim bray's dare to less). It
is desirable to achieve maximum interoperability
for some realizable definition of interoperation.
o It is desirable to liaison. The numbers of liaisons
geometrically extend the time to closure.
o It is desirable to use the same tools. Tools that
are tuned to the precise application are more efficient.
o It is desirable to use the same markup productions.
Object models vary, like tools, by application and the
markup must be usable by the model without transformation.
One could list more but those are revealing. One can't
solve polarities; one manages them, as said elsewhere.
So they may or may not be ignoring it. We are in a culture
of conflicting primary goals. This is common in emerging
cultures. To change cultures, one names, observes and
tests behaviors. Luckily, a lot of our operant conditioning
was accomplished with positive reinforcers. Negatively
reinforced behaviors are quite expensive to regroove.
Change the reinforcement strategy and the semiotic
prompts, and the culture will change accordingly.
Intellect is applied to emotions. It does not oppose them;
it is a selector mechanism over the semiotic sets that
prompt behaviors.
len
From: Simon St.Laurent [mailto:simonstl@simonstl.com]
clbullar@ingr.com (Bullard, Claude L (Len)) writes:
>There is a granularity of identity issue there. One does
>not typically extract one face from an indexed face set
>and use it elsewhere. Maybe the same can be said for a
>line segment or a single coordinate. One can argue as
>some will that meaningfulness is with the user and that
>the format should enhance that to the maximum degree
>possible. On the other hand, coordinates, for example,
>are seldom atomic as meaningful units except to the
>renderer unless one is working in a geo system of
>map coordinates where coordinates are paired with
>meaningful names (think intersection of two
>highways). So in isolation, the decision to use
>a number list makes sense. When one considers
>reuse in a different semantic system, the case can
>be different.
I worry that all of these groups think about their projects only in
isolation, and thereby throw away the supposed interop benefits that XML
was going to buy them. All they end up with is vague human readability,
and don't even get that once humans hit the number lists.
Why bother using XML in those situations? All it produces is a lot of
whining about parsing costs while the benefits are seriously limited by
the refusal of committees to create standards which take advantage of
the format they use at their base.
>How theoretical is this?
It's not, unfortunately.
>I don't know and maybe
>it varies case by case, but it still seems odd to
>me to have at least four XML languages with four
>different dialects for coordinates.
Different dialects, sure - but also a pattern of throwing away the tools
XML offers for managing such differences.
>We may wish to look at different combinations of
>namespaces to see just how jangly the clash really
>is. X3D and SVG are, IMO, obvious examples of
>an opportunity to work together. CAD formats
>(computer aided design) are another but are a
>bit further into the future.
I don't think there's much point in guessing what will and won't have to
work together - the future's not the committee's to pick. Mark the data
up reasonably in the first place, and at least the next round of people
will have one fewer battle to fight.
|
