Subject: RE: [xsl] sum function and math expressions From: "Touchtel" <omprakashv@xxxxxxxxxxxxxxxxx> Date: Sun, 10 Apr 2005 09:17:35 +0530 |
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 ======================================================================
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] sum function and math exp, Wendell Piez | Thread | [xsl] does xsl:output method xml gu, James Fuller |
RE: [xsl] testing for string and nu, Michael Kay | Date | [xsl] last Re: [xsl] testing for st, James Fuller |
Month |