[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: InkML

• To: "'Simon St.Laurent'" <simonstl@s...>, xml-dev@l...
• Subject: RE: InkML
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Thu, 21 Aug 2003 10:42:04 -0500

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@s...]

clbullar@i... (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.

• Follow-Ups:
  • RE: InkML
    • From: "Simon St.Laurent" <simonstl@s...>

• Prev by Date: RE: A standard approach to glueing together reusable X ML fragments in prose?
• Next by Date: RE: Postel's Law Has No Exceptions
• Previous by thread: RE: InkML
• Next by thread: RE: InkML
• Index(es):
  • Date
  • Thread