[sc34wg3] Line breaks in CXTM

[Kal Ahmed]

On Fri, 2004-03-26 at 14:43, Steve Pepper wrote:
> Kal,
> 
> As you know, Ontopia has implemented CXTM in the Omnigator.
> I have now tried to use it and encountered what I consider
> to be a serious problem:
> 
> No allowance is made in the spec for non-significant line
> breaks in the CXTM output. This leads to very long lines
> indeed. In the extreme case (which is very common) it results
> in the whole topic map being on one line. As an example, I am
> attaching the CXTM output from the topic map jill.xtm that is
> distributed with the Omnigator.
> 
> There are two problems:
> 
> First of all, this output is extremely difficult for a human to
> read (at least in a non-XML aware editor or viewer) -- and
> humans *will* have to read these things, e.g. when developing
> test suites.
> 
> Secondly, the most readily available diff tools (such as Unix
> diff) won't work with such documents because they are line or
> record oriented. Again this is a great inconvenience which I
> think is unnecessary.
> 

I agree that this is a problem for debugging tests that fail - its not
really a problem in terms of testing for conformance or non-conformance
as you can really on a content hash to do the comparison work for you.

> I would like therefore to propose that the spec be amended to
> include the insertion of suitable line breaks. Essentially
> section 5 should specify the insertion of line feeds such
> that canonicalization according to XML-C14N would result in a
> document with line feeds after every end-tag, and also after
> every start-tag for elements that have element content or are
> empty.
> 

As long as it is kept that simple I don't think I have any problem with
this proposal - I just don't want to get into specifying a
pretty-printing algorithm because I think that the application does not
justify that. Can you live with that ?

I'll be putting together some proposals for fixes to a couple of bugs I
found in the CD while doing the TMAPI-based implementation of CXTM, so
I'll add that to the list.

> Can we agree on this quickly so that both of the current
> implementations (i.e., yours and ours) can be updated before
> the Amsterdam meeting?
> 

My implementation is now on hold because it is built on top of TMAPI
which is in a state of flux as it approaches 1.0  - trying to keep my
TMAPI implementation and the CXTM implementation in line with every
TMAPI change was too hard so I'm not going to progress either until
TMAPI 1.0 is finalised. Thats a shame because I really hoped to have
another CXTM implementation announced by Amsterdam :-(

Cheers,

Kal

-- 
Kal Ahmed <kal@techquila.com>
techquila