[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XSL Requirements (was: Microsoft extensions to XSL)

Subject: RE: XSL Requirements (was: Microsoft extensions to XSL)
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Sun, 15 Nov 1998 09:12:50 -0500
funny sample system requirements list
Hi Oren,

It seems that you touched something: the language implicit intents. A
language is successful when users intents is met by the language intents. If
I understand you well you say: Are we embracing too large with XSL? Is it
bringing too much complexity in a language to be at the same time a
formatting and transformation language?

We can say however that a lot of formatting processing are in fact
transformation processing. For instance, to format in PDF in to transform a
XML derived grammar into a PDF grammar. But the latter still has the same
underlying structure as the former.

An other problem class is structure transformation. That is where, maybe, we
stretch too much and goes beyond XSL capabilities.

So, could we precise that the XSL intents are in fact transformation from
one grammar to an other by keeping the same underlying structure?. I mean
here, to have a strict one to one correspondence from one grammar to the
other.

So, it seems that we have a twofold problem:

a) Do actual XSL is missing something to fully address a complete
transformation from one grammar to an other with a one to one mapping
(otherwise we skip or omit something)? Is this an issue (the language has
flaws) or that we are still in the learning process and do mistakes when we
apply it? If the language has "gaps", we try to compensate by adding
"scripting" add-on like we do with other kind of pattern match languages
like, for instance, "expert system" languages where procedural languages can
augment pattern match with constructs not included in the specialized expert
system language (Ref: take Clips has a sample expert system language). In
the last case, expert system language designers discovered (couple years
ago) that pattern match languages often needs procedural languages to fill
the gap between a full application and a lab toy. Its funny to see that
these "pattern match" languages started often as a separate design process.
An other way would have been to add pattern match capabilities to already
available procedural languages. Like, for instance, to ask the question: Can
we expand XSL with a procedural language, instead of asking can we add
pattern matching to this ......... (fill the blank) procedural language. so
A) do we add procedural capabilities to pattern match languages like XSL or
B) do we add pattern match capabilities to procedural languages (I mean here
new pattern match constructs, not actual constructs used to build procedures
to do pattern match!)

b) Actual XSL is not suited to do structural transformation and this kind of
processing do not seems to be part of the authors intents. Or that, maybe,
it is really the intent from the authors to cover that area but they don't
know yet how to express this "tacit" knowledge into "explicit"
specifications. Or simply that this group do not suffer from "groupthink"
and it take some time to process different point of views. As we all know, a
lot of code is in fact used to resolve the "impedance mismatch" between
system. Just to recall, an impedance mismatch is a structural mismatch. For
instance, relational database do not match to languages like C++ or Java.
Object database do have the same constructs and therefore match with the
same to mentioned languages (this is just an example, don't start a thread
on the virtues of one language or DB on an other, that is not the point!).
So, we actually use, most of the time, procedural languages to resolve the
mismatch from one structure to the other. For example, to transform data
stored in a relational database into XML formats. It seems that XML is
closer to object storage systems than to "relational" systems. So the need
for mismatch resolution is greater for relational DB transformation into a
display format being for example XML+XSL or directly HTML. Thus, this is an
area where XSL is of no use actually. It seems that some people think that
this kind of transformation should be kept out of XSL and that this latter
should be limited to only rendering transformation.

Either we keep XSL in a fuzzy set and let it "learn" from "real"
implementations or establish at the start its limits. Basically, let it
evolve with creativity or set a standard.

One thing remains, XSL do not fill all our "transformation" needs. Maybe,
the real solution will come from a different point of view we didn't saw
yet: Add pattern match capabilities to an actual procedural language. Or
that finally more will discover the "integration" potential of XML (a great
tool to create whole-parts structures) and finally creates this needed tool.
Thus, either the design group is not there yet, either the full problem is
out of reach to them, either we are simply to impatient toward a slow
process and that some XSL generations is needed before we get this baby
grown into adulthood.

Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com

> -----Original Message-----
> From: owner-xsl-list@xxxxxxxxxxxxxxxx
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of Oren Ben-Kiki
> Sent: Sunday, November 15, 1998 6:12 AM
> To: xsl-list@xxxxxxxxxxxxxxxx
> Subject: XSL Requirements (was: Microsoft extensions to XSL)
>
>
> Ed Nixon <ed.nixon@xxxxxxxxxxxxxxxxx> wrote:
> >I think this might be the point at which we could sit back and
> take a look
> >(again?) at the requirements document. I say this because I assume the
> >requirements are agreed to (more or less) by the consortium's membership
> and,
> >consequently, form the scope and intent of the specification. I hope the
> >process has enough integrity that the requirements are a valid discussion
> >locus.
>
> The intent and scope of XSL are missing from the requirements document. In
> the XSL draft itself we have:
>
> "XSL is a language for expressing stylesheets. It consists of two parts:
>
>   1.a language for transforming XML documents, and
>
>   2.an XML vocabulary for specifying formatting semantics.
>
> An XSL stylesheet specifies the presentation of a class of XML
> documents by
> describing how an instance of the class is transformed into an
> XML document
> that uses the formatting vocabulary."
>
> IMVHO mixing the two intents in a single standard is a mistake. There's a
> real need for a language which targets just the first part - the
> interest in
> XML demonstrates and drives this need. The second need can
> obviously benefit
> from a transformation language, but is really a separate concern. It isn't
> different in principle from needing an XML vocubality for specifying
> mathematical formulas, 2D or 3D graphics, invoice data, or any
> other subject
> matter.
>
> >It seems to me that a lot of what is going back and forth here might
> >either disappear or be improved in quality and relevance if we
> communicated
> in
> >terms of the requirements.
>
> Right. I think we have a basic disagreement between people who use merely
> the first part of the intent - XSL as a transformational language - and
> people who also care about the other part, the formatting semantics.
>
> The first group would like a transformational language which is strong
> enough to convert XML into whatever target language they need. Being
> accessible to the end user is a minor concern. The formatting
> semantics are
> irrelevant (unless you are lucky and they are part of the target
> language).
> The XSL sheet is used to as part of some conversion process, say
> taking data
> from a database and presenting it as HTML.
>
> The second group would like a flexible style sheet language for
> HTML graphic
> designers. Being accessible to such designers is a major concern. The
> transformational powers are secondary as long as common tasks can be
> performed (and these don't require much). The XSL sheet is embedded inside
> an HTML document or maybe is used to generate HTML fragments.
>
> Is there any chance of splitting the XSL draft into two - say, XTL
> (eXtendible Transformational Language) and XFL (eXtendible Formatting
> Language)? The XFL people would be able to use a subset of XTL
> suitable for
> graphic designers (say, ignoring scripting, modes and so on),
> while the XTL
> would ignore XFL (since they are translating to some other target
> language).
> Each group would be able to focus on its own needs without bothering the
> other.
>
> Divide & Conquer :-)
>
>     Oren Ben-Kiki
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.