Xslt as oneway encryption scheme?

["Jens Jakob Andersen" <f0p@post.dk>]

Hi

Having this equation,

Xml*xslt=output 
Output/xslt!=xml

and ignoring the issue that we do not yet have a standard for the division operator, xslt is efficiently a oneway encryption scheme.

This raises some questions:
-Is this good?
-Is this useful, and where?
-Should this be input to the next gen. Xslt process?

I can see that in some areas it would be nice to be able to reverse engineer a given output back to the xml document behind that output. And the current xslt standard doesn't support this.

Northern regards from JJ in the snowstorm at the XML Finland 2001


less_ mean throwing out parts
    > of XML 1.0 that are not frequently used and redesigning XML to be better. My
    > concern is that the attempt to redesign XML (e.g. XML 2.0) will be worse not
    > better. I am willing to be convinced otherwise.
    
    At this point I'm not sure I care very much where XML per se heads. I
    think it's been clear for a long while that XML's future has little to
    do with the original philosophy of XML 1.0.  What began as a prudent
    simplification has long since been hijacked and turned into yet another
    exercise in complexity.  About all that seems to remain is some small
    chance of reading data by hand as it goes across the wire.
    
    So I'm perfectly happy to throw away the parts of XML 1.0 that seemed
    extraneous from the outset, keeping only a basic notion of labeled
    structured content. I'll call that 'markup' until I find a better term,
    and (perhaps) politely ignore efforts that demand using more than that.
    
    Going back to those basics seems more likely to me to keep XML from
    exploding into lunatic complexity than does continued endorsement of
    various tree-decorating schemes.  That these decorations have no
    canonical representation in instance form - no, I don't count the
    internal subset for that - is yet another cause for concern.
    
    > I agree that we should get on with doing more, but that means building upon
    > what we have -- creating a pyramid that uses what we have as a foundation,
    > rather than adding more and more on top while we chip away at the base --
    > that would be an upside down pyramid.
    
    The pyramid's been upside down for years now.  Compare pretty much any
    spec built on XML 1.0 to XML 1.0.  (Namespaces in XML is an exception,
    but I'll refrain from calling it a good one given the years of circular
    discussion it's     

[Message truncated. Tap Edit->Mark for Download to get remaining portion.]