XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] Is it time for the binary XML permathread to start up again?

Yes.

len


Comments interspersed...

From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 

Alessandro Trigila writes:

> Fast Infoset doesn't try to be extremely tightly coded.  We tried to
> find a good balance between ease of implementation, 
> encoding/decoding speed, and compactness.  So there is still room 
> for gzip to remove some of the residual redundancy.

>OK, that makes a lot of sense.  Still, one has to be careful.  There's a 
>line of reasoning that goes:

> a) Fast Infoset is about speed. 

> GZIP is about compression

Ultimately fast vs inconveniently slow?

>That's why there's still redundancy that gzip can find.
>b) If we're willing to take the result of what we computed quickly and run 
>it through gzip, we can make it small after all, but then it will be 
>slower.

Yes.  Hmm, object density in RAM.  The CPU is not the problem.  The choice
of design for the density of the objects is.  RAM over rate=of-ID loads.

>That's not to say that in the 2dimensional space vs. time plane you might 
>not wind up for some purpose at a happy compromise by running FI and gzip,

Perhaps when binding s collection for pre-load.  I don't care if it is slow
if for the cost of syntax the feature set bound is at some distribution in
the coordinate space.  IOW, how dense is the
complex/related/vector-representation of objects by proximity and rate of
motion/change.

In author space, it is the complexity of the application relationships:
objects in Ram, dull but measurable.

Markup systems cost benefits are measured by the density of consumable
relationships, ie, the possible namespaces in a wrapper hypermedia language.
Data is common.  Semantic density is king. 


len

 
but it's far from obvious in advance that the two are complementing rather 
than diluting each others' best qualities in general.   Would I be right 
in guessing that you shouldn't even consider doing the gzip step if you're 
interested mainly in reducing CPU overhead?

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------





_______________________________________________________________________

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@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


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

Copyright 1993-2007 XML.org. This site is hosted by OASIS