Something I'm just wondering for the sake of learning more...

Had XSLT only defined an xsl:include in the spec and did not define an
xsl:import such that I assume it would force the authors to use
template priorities to establish precedence.

Plus, the original specification would have
needed the equivalent of the XSLT 2.0
<xsl:next-match/> in order to allow the creation
of the onion-skin overriding stylesheet.  Though
even with that the inability to override globals
would be sadly missed and cripple important functionality.

Would XSLT...

1. Be lot less powerful such that you could not implement something in
an xsl:import-less XSLT?

I'll cite again the ability to tweak the
behaviour of a read-only stylesheet.  There is
the scenario I mentioned earlier of creating the
"editor's rendition" stylesheet by exploiting the
"user's rendition" stylesheet with overriding behaviours.

Also, imagine it is the 11th hour of a project, a
stylesheet has been through some kind of quality
assurance, and the boss comes up with a
last-minute change.  The well-defined semantics
of <xsl:import> means that the onion-skin
overriding stylesheet can redefine global
declarations used by the imported stylesheet, and
do so without creating declaration
collisions.  The new combined system works as
desired and you haven't touched the base
stylesheets that have already gone through tests.

As careful as we all are when we make changes to
existing stylesheets, using <xsl:import> you can,
hand on heart, claim you didn't touch the base
read-only stylesheets and you've implemented all
of the changes you need through the onion skin.

You can't do this in XQuery because "global"
declarations are only global to the module and
the including modules, but not to any other modules.

2. Be much more difficult to program certain things or perhaps just
less convenient?

Rather than "more easy or more difficult" how
about "more safely and more conveniently"?

Declarative solutions come up with the same
results as imperative solutions, but you have far
more flexibility adapting and leveraging a
declarative solution than you do an imperative
solution.  If programs never needed maintenance,
then this discussion would be less
important.  Though the powerful XSLT features are
not only exploited when maintaining a stylesheet
... they are also very useful when developing a stylesheet.

3 Be something else....

It would be more imperative and less
declarative.  The declarative nature of XSLT
allows all of the global constructs to be
overridden by simply declaring them in a module
with higher precedence (more importance).

Without it, stylesheet writers would have to
think more imperatively about their stylesheet
fragments and have to "program around" the
competing declaration issues, rather than let the
specification arbitrate between competing
declarations in a well-defined fashion.

Sadly, programmers with imperative programming
styles (that includes XQuery writers) who
approach XSLT either don't understand the
declarative benefits of using <xsl:import> or
simply don't bother looking because they are
stuck thinking in an imperative fashion rather than a declarative fashion.

I wonder if confusion arises from the words include and import not
really conveying much logical difference in functionality given that
no doubt studying these terms is a good idea before using them as I
did with MK's book.

It is awkward to convey complex semantics in a
single word or a single attribute.  I think the
specification writers did very well by using
"include" as many programmers think of the
concept, and "import" as something with different inclusion semantics.

Encountering lower-precedence imported constructs
before higher-precedence constructs in the
importing fragment is likely helpful to the
implementer (I don't know, I've never implemented an XSLT processor).

Distinguishing different semantics with different
names can be, I believe, better than overloading
dramatically different semantics on constructs
with the same name in the presence of optional
attributes.  Though, of course, a balance has to
be struck regarding "dramatically different
semantics" or we wouldn't have any optional attributes on any elements.

I think it is unfair to criticize in hindsight
the choices made by designers of the
language.  There was plenty of time at the time
for the choices to be debated, and many talented
people participated at that time to come up with
meaningful choices.  It seems too easy to say now
"they did it wrong" when in fact what they did
has been very successful.  XSLT is a very
powerful language that can be used very
powerfully and very simply when used correctly.

I also see a lot of hindsight criticizing XML
namespaces unfairly.  The time to have debated it
was the time it was being designed, not after the fact.

I would rather code be more specific and write a bit more code than
there be rules like the ordering of the xsl:import giving different
precedence.

I think it better the code specify the import precedence
with english given that would take only a little bit of code for the
extra clarity and we wouldn't be having this discussion I assume.

I disagree.  The specification is
clear.  Absolving the stylesheet writer of
understanding the specification doesn't necessarily help them.

This feature strikes a good balance between
helping the implementer (requiring the import
constructs to be first in the stylesheet) with
helping the stylesheet writer (clear semantics on
the difference between import and include).

I suppose generally the things I don't like about xslt are the things
that happen as your learning that language but are not "clear" why
like when you get xmlns="" or some other namespace output on your
elements for the first time and your just thinking to yourself I don't
want that to happen. I didn't ask for that to happen.

But you did ask for that to happen by the rules
of the language.  The language is designed as it
is to accommodate far more powerful features that
what your "first time example" demands.  Why
handcuff the environment only to do simple
things?  My consulting customers have been very
pleased with the very powerful solutions I've
delivered that meets their very exacting
requirements in ways that other languages cannot
do as easily or as easily maintainable when their
requirements morph into new requirements.

It's really not
clear to a new user and a bit annoying in my view. (hmmm sorry for the
"clarity" tangent but that is my one and only beef with xslt so it
came out... I just wish xslt output what I wrote exactly.

Then perhaps it wouldn't be nearly as powerful as
it is with that imperative perspective.  There
would be fewer opportunities for the processor to
help you by implementing your declarative code
the best way imperatively behind the scenes.

It seems
much easier and more clear to add a namespace on my own than take it
away. I suppose this should be in a different post..)

I approached XSLT (and before that DSSSL in 1996)
with the perspective of an imperative programmer
(I'm a second generation programmer as it was my
father's trade and I started programming in
imperative FORTRAN (FORmula TRANslator) 40 years
ago in June 1971).  I made all of the mistakes in
XSLT that other imperative programmers make.  I
recognize these mistakes in the classroom when
the students make them and I can show them the
light provided by XSLT.  The specification was
designed by brilliant people who have given us
tremendous power.  Without that power, if XSLT
was designed only for "the simple first-time
attempts", then there would have been no reason
to move to XSLT from other languages.

But because XSLT is designed the way it is, and
doesn't cater to only "simple first-time attempts
at transformation", it is far better suited than
all other languages for certain classes of problems to be solved.

Remember that XSLT was initially written as
chapter 2 of the XSL (XSL-FO) specification.  It
was only taken out of the XSL specification when
its amazing design principles were seen to be
useful in other transformation scenarios.  In
publishing scenarios, the declarative nature of
XSLT is ideal and I've made a very successful
living out of implementing customer solutions in this area.

And I've been able to exploit the powerful
declarative nature in non-publishing solutions as
well because the language features allow me to do
so in XSLT much more easily than other languages.

Heck, I never understood APL but users of APL
found it a tremendous language for the class of
problems APL was designed for (matrix
manipulation if I understand correctly).  It too
was declarative.  I don't think APL programmers
would want to have to implement their solutions
imperatively.  If my customers came to me with
problems requiring matrix manipulation, then I'd
take the time to (try to) learn APL and solve
their problems and get paid.  Thankfully, they don't!

Horses for courses.  There is no |ber-programming
language.  There is no |ber-programming
style.  I'm glad XSLT was not hobbled to be like other programming languages.

--
Contact us for world-wide XML consulting & instructor-led training
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Google+ profile:    https://plus.google.com/116832879756988317389/
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal