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

RE: Xqueeze: Compact XML Alternative

• To: 'Mike Champion' <mc@x...>, xml-dev@l...
• Subject: RE: Xqueeze: Compact XML Alternative
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Tue, 4 Feb 2003 12:44:49 -0600

So we repeat the experience of YetAnotherSubset. 
SGML was designed for Generalized Markup.  XML 
was designed for MarkupOnTheWeb.  XMLSubsets 
would be designed for .... what?  Niceness?

It might be better to let the whats sort that out 
for awhile before prematurely designing subsets. 
Then when there is a call from several application 
domains with credible fielding, begin the work.

Meanwhile binaries are being designed as evidenced 
by the MPEG and X3D work.  These are created to 
satisfy particular needs and that seems best, at 
least, it seems focused, has the least impact 
on the overall web architecture, and provides 
information to best practices while restraining 
the costs to those prepared and willing to bear them. 

As Alaric points out, gzip gives a good file size 
and if that were the only consideration, no binary
is needed.  Experience says that size is not the 
only reason for a binary.  The data structures 
impact the performance given a network messaging 
scenario.  So with some time, something was learned.

Is it time to discuss specifying XML subsets? Sure. 
Is it time to pick one or two?  I'm not convinced. 

Again, the rationale proposed is "fear of what is 
growing in the wild" and that might be seen as 
an unreasonable need for control when the applications 
that have the requirement in the wild are already 
controlling this.  Let a thousand flowers grow? 
Maybe.  I've just not seen the evidence that the 
needs outweigh the risks yet.

Make no standard before it is time.

len


From: Mike Champion [mailto:mc@x...]

It would be *nice* if there were open standard(s) for things like XML subsets that are 
easier to parse and/or alternative serializations of the infoset that are 
more efficient to exchange over standard protocols.  I suspect that a lot 
of people are reinventing the same wheels, and it would be nice to see 
standards in this area. 

• Follow-Ups:
  • Re: Xqueeze: Compact XML Alternative
    • From: "Rick Jelliffe" <ricko@a...>

• Prev by Date: Re: Xqueeze: Compact XML Alternative
• Next by Date: Re: Xqueeze: Compact XML Alternative
• Previous by thread: RE: Xqueeze: Compact XML Alternative
• Next by thread: Re: Xqueeze: Compact XML Alternative
• Index(es):
  • Date
  • Thread