mike | 30 Nov 22:20 2005

The first public Working Draft

The first public Working Draft of the XML Binary Characterization Use Cases has
been published. It's not complete as a number of use cases still need to be
written, and there is still some editorial work to be done on the existing
ones, but it's the first taste of what you'll get from this working group, and
your first chance to provide feedback.

As you may know, the task of the XML Binary Characterization WG (or XBC WG for
friends and family) is to gather information that will help determine the
nature of [the] use cases [for binary XML], characterizing the properties that
XML provides as well as those that are required by the use cases, and
establishing objective, shared measurements to help judge whether XML 1.x and
alternate (binary) encodings provide the required properties.

This is to be a short-lived WG that will not produce Recommendations (but rather
just WG Notes indicating its findings), so if you have feedback to provide you
only have until circa the end of next March to give it. After that, either the
WG will have failed in providing answers in time, or it will form an opinion on
whether the W3C should produce a standard in that area or not. So give it now!
Even if it's just the first document in a series and it isn't yet complete,
there is already meat to comment on.

Best Regards

(Continue reading)

David Ryan | 24 Aug 05:59 2005

Interested in feedback.

Hi XML Binary's,

It seems this discussion list has been very non-eventful recently.  Is 
anything happenning behind the scenes?

Just to spur a bit of discussion, I'd be interested in some feedback for 
a white paper I just released.  It provided some technical details for 
Argot, my binary encoding technique.  I'm still working on the XML to 
Argot project and will release more details on that when I can.  You can 
find it at http://www.einet.com.au/Articles titled "Argot White Paper".

What else are people working on in this list?


reagle | 20 Aug 19:00 2005

A cada dia que passa ti amo mais . . . reagle Liga pra mim ! ! !

Cartões › Datas Especiais
De: Amor eterno
Para: Meu Grande Amor
Terra networks - Todos os direitos reservados.




ij | 17 Aug 00:48 2005

De auguem que te ama muito . . . saudade ij

Cartões › Datas Especiais
De: Amor eterno
Para: Meu Grande Amor
Terra networks - Todos os direitos reservados.




Rui Catalão | 23 Jun 12:30 2005

Error opening Xml file on Excel 2003 - "invalid character was found..."


can someone tell me why this error append when I try to open a xml file with  Portuguese characters (ex "é" or á or é) ?

"File cannot be opened because : An invalid character was found is text content. Line 204, Position 24. <NOME_CLI>Jos"  (complete word : "José").

Thank you

Rui Catalão
rcatalao <at> santogal.pt

Attachment (smime.p7s): application/x-pkcs7-signature, 4094 bytes
Rice, Ed (HP.com | 24 May 19:26 2005

TAG opinion on XML Binary Format

 TAG opinion on XML Binary Format The TAG has reviewed in detail the documents [1,2,3,4] prepared by the XBC workgroup [5].  While we very much appreciate the significant progress that these notes represent, the TAG believes that more detailed analysis is needed before a W3C Binary XML Recommendation is sufficiently justified.  We are taking no position at this time as to whether Binary XML will prove to be warranted, as there seem to be good arguments on both sides of that question.  Rather, we are suggesting that further careful analysis is needed before the W3C commits to a direction. The TAG believes there are disadvantages as well as potential advantages that will result from even a well crafted Binary XML Recommendation.  The advantages are clear: a successful binary format is likely to provide speed gains or size reductions, at least for certain use cases.  The drawbacks are likely to include reduced interoperability with XML 1.0 and XML 1.1 software, and an inability to leverage the benefits of text-based formats.  These are important concerns.  Quoting from the Web Architecture document[6]:    "The trade-offs between binary and textual data   formats are complex and application-   dependent. Binary formats can be substantially   more compact, particularly for complex   pointer-rich data structures. Also, they can be   consumed more rapidly by agents in those cases   where they can be loaded into memory and used   with little or no conversion. Note, however,   that such cases are relatively uncommon as such   direct use may open the door to security issues   that can only practically be addressed by   examining every aspect of the data structure in   detail.    "Textual formats are usually more portable and   interoperable. Textual formats also have the   considerable advantage that they can be   directly read by human beings (and understood,   given sufficient documentation). This can   simplify the tasks of creating and maintaining   software, and allow the direct intervention of   humans in the processing chain without recourse   to tools more complex than the ubiquitous text   editor. Finally, it simplifies the necessary   human task of learning about new data formats;   this is called the "view source" effect." We therefore believe that the benefits of a binary XML must be predictable and compelling in order to justify development of a Recommendation.  In particular, we suggest that a quantitative analysis is necessary.  For at least a few key use cases, concrete targets should be set for the size and/or speed gains that would be needed to justify the disruption introduced by a new format.  For example, a target might be that "in typical web services scenarios, median speed gains on the order of 3x in combined parsing and deserialization are deemed sufficient to justify a new format."  We further suggest that representative binary technologies be benchmarked and analyzed to a sufficient degree that such speed or size improvements can be reasonably reliably predicted before we commit to a Recommendation.  No doubt, any given set of goals or benchmarks will suffer from some degree of imprecision, but if the gains are sufficiently compelling to justify a new format, then they should be relatively easy to demonstrate.  In short, actual measurements should be a prerequisite to preparing a Recommendation. In doing such measurements, we believe it is essential that comparisons be done to the best possible text-based XML 1.x implementations, which are not necessarily those that are most widely deployed.  Stated differently: if XML 1.x is inherently capable of meeting the needs of users, then our efforts should go into tuning our XML implementations, not designing new formats.  Benchmark environments should be as representative as possible of fully optimized implementations, not just of the XML parser, but of the surrounding application or middleware stack.  We note that different application-level optimizations may be necessary to maximize the performance of the Binary or text cases respectively.  Care should especially be taken to ensure that the performance of particular APIs such as DOM or SAX does not obscure the performance possible with either option (e.g. both SAX and DOM can easily result in high overhead string conversions when UTF-8 is used.) The TAG would also appreciate clarification as to how many formats are likely to be included in a Recommendation; it's not clear whether the proposal is for one binary xml format for all cases, or if multiple formats are to be endorsed.  The use of multiple formats is likely to further reduce interoperability. We feel that introduction of a binary format would be an important development for those who might benefit from its size or speed, but also for those who might be impacted by its impact on interoperability and perspicuity.  Therefore, in order to justify a potential new format, the TAG would like to see the above issues addressed.  As stated above, we make no prediction as to whether such an analysis will ultimately confirm the need for Binary XML;  if it does, we will be glad to support development of a Recommendation at the W3C.  [1] http://www.w3.org/TR/xbc-use-cases/[2] http://www.w3.org/TR/xbc-properties/[3] http://www.w3.org/TR/xbc-measurement/[4] http://www.w3.org/TR/xbc-characterization/[5] http://www.w3.org/XML/Binary/[6] http://www.w3.org/TR/webarch/#binary



Norman Walsh | 12 Apr 21:30 2005

Comments on XBC Characterization

I find the Characterization document interesting, but also quite

From an editorial perspective, the fact that Section 7 intentionally
obfuscates the relationship between the candidate algorithms and the
columns in the table, *but fails to explicitly say this in the
document* is a significant editorial problem. Beyond the editorial
issue, I think the document needs to justify why this was done.

Also, there are six numbered Notes below that table, but I can find no
indication of what those notes correspond to. Perhaps they are
intended to refer to particular columns in the table. If that's the
case, then the meaning of each note escapes me.

Under the MUST NOT Prevent heading in the table, we find that
(textual) XML "Prevents" processing efficiency, small footprint, space
efficiency, and forward compatibility. I don't find the properties
document's discussion of these properties convincing on this score.

From a technical perspective, what concerns me most is that the note
says "[the] Working Group has not done any measurements on submitted
formats" and yet concludes that Binary XML is needed and feasible.

It may very well be needed and feasible, but I don't find the existing
documents convincing.

                                        Be seeing you,


Norman.Walsh <at> Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
Norman Walsh | 12 Apr 20:47 2005

Comments on XBC Use Cases

I agreed to review the XML Binary Characterization Use Cases document
for the XML Core WG. I realize I sent my notes to the Core WG but
neglected to send them here. FYI, here are my notes, amended slightly
to better suit this context. (These are my notes only, I do not claim
that they represent the consensus of the Core WG.)

Alas, I don't feel much the wiser for having read the Use Cases
document. The document lays out a series of use cases and explains why
each case requires binary XML. For the use cases I understand, the
arguments seem to have merit, though none of them left me feeling
really persuaded.

A few specific comments:

Section 3.6 argues for a binary encoding for "electronic documents" on
the basis that documents contain images and fonts and video and such
and because non-linear navigation is required.

I am *utterly* unmoved by the arguments, though perhaps personal bias
plays a part. The long-lived nature of documents makes a textual
encoding of the information an overwhelmingly superior choice, in my
opinion. I'll gamble that my textual XML documents will be readable,
at least by humans, in 1,000 years. I won't make that gamble with
*any* binary format. XML already has good mechanisms for dealing with
images and video (linking) and fonts (stylesheets, either embedded or
external, that separate presentation from content). The fact that
there's no good packaging specification to bind all these components
together into a single unit is a problem, but not one that requires
binary XML to solve.

I don't know why the document states that an index requires a binary
format. I'm pretty sure that the amount of cleverness necessary to put
an index at the beginning of a text document is managable. I'm also
not convinced that "update" requires a binary format, though I concede
that the challenges are significant.

And I also don't believe the assertion that text "represent[s] a
decreasing fraction of all electronic documents". If that is true, I
would like to see the evidence that supports it.

In fact there were other assertions, like this one:

   A compact binary format is likely to be intermediate in size
   between a zlib compressed XML stanza and the original XML, while
   retaining high processing speed.

that seem reasonable on the surface but that I'd be reluctant to
accept as fact without some measurements to back them up. But maybe
that's in one of the other documents.

                                        Be seeing you,


Norman.Walsh <at> Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
Dan Connolly | 7 Apr 19:46 2005

why obscure Feasability section?

The table in...

as numbers across the top followed by an un-numbered list
of candidate technologies. Why is the correlation obscured?
If we can't talk about these things openly, how can we move

I have read a number of comments on the recently released
XBC documents that I largely agree with. I would prefer
that people with comments send them to public-xml-binary
for themselves, but I want to be sure readers of public-xml-binary
know about these comments even if they don't regularly
read these blogs...

I don’t care if anyone wants to go off and produce their own data
interchange format, binary or not, open or not, standardized or not,
mapped to XML or not; as long as they don’t call it XML. “Binary XML” is
an oxymoron.


The working group has determined a number of MUST properties for their
eventual Not XML format:

      * Directly Readable and Writable 
      * Transport Independence
      * Compactness 
      * Human Language Neutral
      * Platform Neutrality
      * Integratable into XML Stack
      * Royalty Free
      * Fragmentable 
      * Streamable 
      * Roundtrip Support 
      * Generality 
      * Schema Extensions and Deviations 
      * Format Version Identifier 
      * Content Type Management
      * Self Contained 

I predict they're not going to be able to create a format that satisfies
all their musts.
 -- http://www.cafeconleche.org/#news2005April1


Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Dan Connolly | 7 Apr 19:31 2005

binaryXML-30 discussion in/near www-tag

Since the release of ...

the TAG has resumed discussion of issue binaryXML-30

While the TAG hasn't made any group decisions yet, we did
discuss it as a group last Tuesday...

Norm said he had done some review for another group, though
there was no particular reason he hadn't
sent this message to public-xml-binary...

 Review of binary use cases 
 From: Norman Walsh <Norman.Walsh <at> Sun.COM>
 Date: Thu, 31 Mar 2005 12:32:51 -0500

And since then, Noah cited some work on XML optimization techniques

and while the subject lines don't show it, the thread quickly
went to substantive discussion of the XBC documents and binaryXML-30.
In particular, Ed's message seems to be more of a comment
on the XBC documents than on the XML optimization work...

I'm not sure if the discussion should be cross-posted to
public-xml-binary or what, but for anybody that is following
public-xml-binary and not following www-tag, here's a


Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

bagran | 11 Mar 11:35 2005

how many models of your ontology

Jim --

You wrote:  >From a practical point of view, does the number of models ever 
enter into

You may be interested in a formal approach that yields exactly one model [1].

There's a practical system based on this, live, online with a number of 
examples, at www.php-tutor.com .  The author- and user-interface is
simply a browser, and experimental use is free.


Best regards,