Re: PSVI issues

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| 1) The functionality provided by the 'psvi-required' attribute is
|    perfectly reasonable and self-contained, and it should be retained
|    unchanged.  If I want to write pipelines which simple won't work
|    (statically) when a processor doesn't support the PSVI, that's what
|    I'll use.

By which you mean, you'll write

 <p:pipeline psvi-required="true">
   ...

And any impl. that don't support PSVI annotations will simply refuse
to execute it. Yes?

| 2) I am unconvinced that we need to provide a means to tell processors
|    which do support the PSVI whether or not they need to do so when
|    executing a particular pipeline.  That feels like an
|    product-specific optimisation to me, and as such _finally_ gives me
|    an example of a realistic use for <pipeinfo> -- a product is free
|    do define a <pipeinfo> child which can be inserted before
|    e.g. validate steps to say, in effect, "I do/don't care about the
|    PSVI".
|
|    I'd rather wait until we see if such annotations turn out to be
|    provided, and what they look like, before trying to add something
|    along those lines into the language.

Makes sense to me.

| 3) Having said that, I think it _does_ make sense to provide a means
|    for pipeline authors to do something at runtime depending on PSVI
|    support.  But I think the minimum necessary to declare victory is
|    just psvi-available(), which if true means the processor claims
|    it's passing PSVI information along.  No granularity or locality is
|    implied, that is, the value should be the same at all times/places
|    within a given episode.

That's what I thought I wanted last week and I was convinced on the
call that all I really wanted was psvi-supported(). Do you think
that's no longer sufficient?

| 4) Wrt to the amount of support required, I think we say PSVI support
|    implies two things:
|
|    a) All PSVI properties produced on the output of a step MUST be
|       available to the steps which take that output as one of their
|       inputs;

Otherwise, what's the point, right? :-)

|    b) Implementations SHOULD preserve PSVI properties across steps
|       insofar as that is consistent with step semantics.  It is
|       implementation-defined what PSVI properties it supports overall,
|       and what PSVI properties are lost by what steps.

I have mixed feelings. Consider p:delete. Does it make sense for that
step to preserve PSVI properties on elements and attributes that it
doesn't delete?

If you validate, delete required elements, then process the document
and your tool chokes because it gets a putatively valid document that
isn't actually valid, well, I suppose we could say your gun, your
bullet, your foot.

Or maybe we could say that PSVI properites can only appear on the
output of the validate steps, p:xslt, and p:xquery (and user-defined
steps).

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Resist the urge to hurry; it will only
http://nwalsh.com/            | slow you down--Bruce Eckel