RE: [xsl] sum function and math expressions

["Touchtel" <omprakashv@xxxxxxxxxxxxxxxxx>]

   Hi,
	Thanks to all the people for having taken up this issue I had raised and
discussed it in detail. I too feared that it might be difficult though I
wasn't sure what the exact problem areas would be until I actually
encountered them. But it did seem and still seems attractive especially
since I have got my xml in a decent looking grid like structure and Iam able
to transform it back to an xml that has a fairly close resemblance to the
original. Maybe If accept the fact that certain constraints are inevitable
then I may still be able to provide this view I mentioned about using XSLT.

	Based on the discussion, it has been observed that the following may be
difficult to recover.

    * the entity structure
    * being able to get a matching DSIG ( How serious is this!!!)
    * all sorts of really ugly whitespace normalization details (including
 within tags) ( Should Whitespace be maintained. I think many would agree to
losing this information for other benefits)
    * single- versus double-quoting of attributes (only with xml
binarization approach I think)
    * namespace prefix usage (Maybe not serious)
    * order of attributes (Maybe not serious)
    * <br /> vesus <br></br> (Maybe not serious)

The following were suggested (pointed out!!) by Michael.
	unparsed entities make it into the XSLT input but not into its output ( is
this same as 1st item above)
	- base URI is lost (Maybe not serious!!!)
	- the isID and isIDREF properties of elements and attributes are lost (I
think - need to check). ( How serious is this. Can this be ignored without
much loss to  functionality of editing)

       The XML binarization suggested by Wendell looks promising and I will
check it out. So will I check out the non-XML wiki approach.

Also Iam including my responses to some comments below:

* you enhance HTML in order to capture info you need (your enhancements
    might be disguised as 'class' attributes and what not)
	I thought of this but then desisted for reasons of scalability as I may
probably have a need to use the class and id attributes at a later time.

* you have serious rules set up constraining what this enhanced HTML is
    (both less and more than arbitrary HTML)
	If this means adding extra tags and attributes not allowed in the HTML DTD,
then I have tried this approach atleast with elements and found it
disrupting the operation of the renderer.

* you have some way of validating to those rules
	if this means with a DTD, then I don't think I have thought of that.

* you have some way to represent, communicate, and teach those rules and
   encourage/help/force users to conform to them

	That I don't think will be acceptable as the whole idea is to make it
easier for people to edit xml in an easy-to-use grid-like view.


        Thanks for all the suggestions. I will look into the various options
I have and decide accordingly. I would appreciate if you could keep the
valuable suggestions going.

Regards,
Omprakash.V









-----Original Message-----
From: Wendell Piez [mailto:wapiez@xxxxxxxxxxxxxxxx]
Sent: Saturday, April 09, 2005 4:03 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] sum function and math expressions


Omprakash,

Over on XML-Dev an entirely different thread is coming (again -- it's a
permathread), which bears on the same issue you asked about.

The context is XML binarization. Steve DeRose (whose name you will find on
the XPath 1.0 Rec) writes:

>I think most people would consider a format "lossless" if you could export
>from it back into XML syntax, and when you parsed the resulting XML you
>got the same DOM as for the original document. If that's enough, it's not
>hard to make a lossless binary format (and mine was lossless, except I
>think it discarded comments and PIs). HOWEVER, this is not completely
>lossless. You still lose (among other things):
>
>    * the entity structure
>
>    * being able to get a matching DSIG
>
>    * all sorts of really ugly whitespace normalization details (including
> within tags)
>
>    * single- versus double-quoting of attributes
>
>    * namespace prefix usage
>
>    * order of attributes
>
>    * <br /> vesus <br></br>
>
>So, until you define "lossless", there's no point in comparing whether two
>products are lossless or not.

These are all aspects you may find problematic in developing an XML editor.
(Well, some of them you really might not think about.) I should think it
would be quite a trick to determine how close to the code the user should
be, in any given case. This is one reason why we see several different
varieties of XML editors in the market, ranging from tree editors through
all the way to souped-up plain text editors -- they all take different
approaches to this problem.

An XSLT transform will have "lossiness" issues with all of the above, and
most XML editors I know of use XSLT, if at all, only to go one way (from
source to presentation) not back upstream.

On line, in the web environment, it looks like the wiki approach (deploy a
lightweight, task-specific non-XML markup language and parse that in back)
is as favored as any these days. XSLT (especially armed with 2.0 regexps)
might actually do well in that scenario. But it assumes the user will allow
a significant gap between WYS (what you see) and WYG (what you get).

Allowing users to edit HTML and then converting that back into XML -- I
think this would only be possible in theory if:
* you enhance HTML in order to capture info you need (your enhancements
    might be disguised as 'class' attributes and what not)
* you have serious rules set up constraining what this enhanced HTML is
    (both less and more than arbitrary HTML)
* you have some way of validating to those rules
* you have some way to represent, communicate, and teach those rules and
   encourage/help/force users to conform to them

As you can see these are daunting tasks, to say nothing of their impact on
the design and maintenance of the XML format in back. (If your writers like
HTML, one might be tempted to go with valid XHTML, perhaps with some local
semantic conventions, and try to live with that.)

Another approach I'm a bit surprised not to see more of is the pure Java
editor set up in quasi-'WYSIWYG' fashion for a single tag set -- a
dedicated Docbook or mini-Docbook editor, say, or TEI ultra-lite. We may
see more of this kind of thing in time.

Wrapping up data delivered by forms in tags one way or another has been
done as long as XML has been around (actually longer).

As you can see, this opens entire landscapes of issues that are broader
than XSL. IMO, XML authorship will remain an issue as long as people want
perfect transparency in their media (which they do, or at least think they
do). (The true artist knows that transparency is achieved through
arrangements of the opaque; but that's a different issue.)

Cheers,
Wendell


======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
   Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================