This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: The hard cocktail of sequence and (node-)set (Was: RE: RE: Postional predicates de-mystified)


> > If not corrected this "feature" alone will become a classical
> > example of bad design.
> >
> > I have pointed out elsewhere some of the unfortunate results
> > of mixing these two
> > very different datatypes into one:
> >
> > http://aspn.activestate.com/ASPN/Mail/Message/xsl-list/908998
> >
> 
> Ah yes, I remember now. All my hens will get eaten by foxes.
> 
> Dimitre, I have a great deal of respect for your opinions, and I think there
> is probably a case to be argued here. In this instance I don't think you
> argue it very well. 

Mike, first of all let me thank you for your tact and politeness... :o)

Maybe you're right that I might be overreacting about this issue.

Alas, I've been spoilt by using a very neat and elegant language, in which a list is
a list, a tuple is a tuple and a tree is a tree. And in this language everything has
its own type, every element of a list is of the same type, as is every n-th
component of a tuple. Every attempt to perform an operation on a value that is not
of the proper type is immediately signaled as error.

However, my reaction is based not so much on theory and aesthetics, but on practical
issues.

> I would be tempted to ask you to put together a more
> careful justification of why you think the group is taking the wrong
> approach, and to submit it. 

I'm very much concerned that with the adoption of XPath 2.0 we'll have to deal with
new kinds of problems, never experienced with XPath 1.0. These will affect every
template, which has a parameter defined and used as a node-set -- this includes all
existing such XSLT 1.0 templates.

Here are some examples:

1. A template is instantiated. It processes its $pNodeSet parameter as a nodeset.
The processing proceeds without problems for the first 999 nodes of $pNodeSet and
considerable output is being produced for a long time. Then when attempting to
process what is assumed to be the 1000th node from $pNodeSet an error is produced,
because $pNodeSet is actually a sequence, whose 1000th element is a number.

This situation is impossible with XSLT 1.0. If something else than a node-set had
been passed as a parameter, this would be found out on the first attempt to use the
parameter. Processing time and output wouldn't be wasted. Debugging would be much
more straightforward.

2. The value of the $pNodeSet parameter is supposed to be a nodeset, and it is a
sequence that contains only nodes, however they are not in document order. The
transformation assumes (legally for a node-set) that the nodes contained in
$pNodeSet are in document order. The result is that the output does not reflect the
document order of the processed nodes -- in many cases it may be unusable. Debugging
can be very difficult.

What is really serious and disturbing here, is that no error will be raised at all.

This situation does not exist in XSLT 1.0.

3. The value of the $pNodeSet parameter is supposed to be a nodeset, and it is a
sequence that contains only nodes, however some nodes are occuring more than once
(in case these nodes are not adjacent in the sequence this example is also a case of
the previous example).

Processing is performed successfully, however the output is incorrect and contains
repeating/duplicating parts.

Once again, no error is raised at all, and sometimes it may even take considerable
time before the confusing error is discovered.

This situation was not known in XSLT 1.0.

> However, while all comments are welcome, I think
> you would be wasting your time. We're now at the stage where people don't
> want to reexamine the fundamental data model unless it's found to contain
> very serious holes; and I think that while it isn't perfect, it is workable.

Mike, I know that if it depended on you alone this "feature" would not be in the
language. I don't have to convince you that this is an issue, because you raised
this issue (Issue-0035 Eliminate heterogenious sequences) and also Issue-0025 about
the need to have type for sequences. And these issues are still flagged as "open".

Is such a language "workable"? Probably we can live with a language, which is just
"imperfect". But a language is hardly inspiring, which allows silently erroneous
processing and never signals an error.

Cheers,
Dimitre Novatchev.









__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]