Disposition of Issues

Discuss now: 47, 155, 136, 48, 144, 116, 44, 93, 162

Discuss later: 35, 151, 160, 117, 58, 173, 56

Resolve: 141, 61, 88, 49, 140, 51, 74


Issue 141: : shouldn't variable connections also be listed in 2.5 Connections ?,

Yes, this is the same as p:option and looks like an oversight.


Issue 61: 3.12 Provide a way to specify the base URI of a document,

The simple solution would be to add a 'href' attribute to p:inline to
name the base URI of the document.  Using 'href' would allow it to
resolve against the base URI of the p:inline.


Issue 35: 2.7.2 Syntax: allow <p:pipe port=secondary/>,

While we should do this and there is little consequence, it does bring
up the issue that we don't have a name for the step from which the
default readable port comes from.  Having the concept of the "default
step" or "preceding step" might make this whole thing more
understandable.


Issue 47: 3.3 Support steps with a dynamic number of ports,

This requires discussion in the context of a live example.


Issue 88: Provide schemas for c:* elements,

Yes.  Ready?  Set?  Go!


Issue 155: Consider adding URI/prefix alternatives for p:xslt’s
initial-mode and template-name options,

Can't this be constructed using the expanded-QName() function and
shortened using an AVT?


Issue 136: default error port ,

Yes.  Action A-265-01 ... Jim?  Jim?  Jim?


Issue 151: Ability to ignore DTD referenced from doctype declaration
when loading documents,

I don't think we have much of a choice.  I suppose an XML processor
could be configured to return empty strings for all external entity
references.  An implementor might provide such a hammer for users to
smash things with ...


Issue 49: 3.5 Provide a mechanism for importing user-defined functions,

Yes.  Do what Calabash does ...


Issue 48: 3.4 Provide improved status information,

This requires some discussion.  I would like to see some use cases but
the p:message seems like the minimum bar.


Issue 160: consider making the match attribute default to '/*' for
p:add-attribute etc.,

I am not a fan of defaults.  But, we should discuss which way this
should go.  We should either add defaults for other steps, possibly as
suggested, or remove the one default that we have.


Issue 144: declare the content type of an inline document,

We should add the content-type attribute and the semantics:

   text/plain - the concatenation of the text descendants
   */xml, *+xml, as current specified
   everything else requires c:data and base64 encoded


Issue 140: Editorial: reword the definition of the value templates syntax ?,

Yes.  The new wording seems clearer.


Issue 117: What are the output media types of p:xslt (and p:xquery),

The processor (XSLT or XQuery) produces various content types via
serialization.  We would have to examine the serialization specified
to know what content type to attach and what conversion
(serialization) to apply to the resulting sequence.

It would be unfortunate for a user to have to copy the serialization
information specified inside the XSLT or XQuery.


Issue 51: 3.7 Write a primer,

Yes.  Should we draw straws?


Issue 116: Semantics of p:cast-content-type,

In the specific case of:

   content type says "application/octet-stream" but I know that it is
in fact "application/xml"

we should consider a "parse" option that would parse input text into
XML.  Similarly, we could do the same for other types but whose
semantics might be implementation defined (e.g.
application/octet-stream to image/svg+xml or application/json).


Issue 58: 3.10.5 Additional steps and enhancements: OS steps,

This needs considerable work.  We should data mine other specs and/or
example build processes for EPUB to see what is needed.


Issue 44: 2.8 Document backwards-incompatibilities,

We should take a moment to review the changes we have made and
document them now before we make too many other changes. This should
be a section in the document. As we go forward, we should review any
change for a backwards compatibility issue and add that to the
appropriate section as part of the change.


Issue 173: Does directory-listing provide the content-type in the
resulting c:file elements?,

I think an include/exclude-content-type regex is the right solution.
We might consider it being a list of regular expressions given the
constrained syntax.


Issue 56: 3.10.3 Additional steps and enhancements: p:eval,

p:eval requires addressing the issue of multiple input/output ports.

We have also consider p:zip/p:unzip

I suggest we spend some time trying to enumerate the list of
candidates we are willing to consider for the 2.0 timeframe.


Issue 74: Register application/xproc+xml media type,

I nominate Henry.  You can thank me later!


Issue 93: Should p:parameters be renamed?,

I may need to re-convince myself.  If we keep them, I have never liked
"param" short for "parameter".


Issue 162: Consider adding @timeout to control potentially long-running steps,

Timeouts seem really general and our choice of using it for particular
steps will likely be insufficient in the long term.  We might want to
consider how we can generalize this and whether this should first be
done by implementor experimentation to gain some experience before we
standardize it.

It is a really good idea that would do well in enterprise environments
where the resilience of the pipeline as a software component needs to
be control and failure needs to be handled gracefully.



-- 
--Alex Miłowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Wednesday, 10 June 2015 14:42:54 UTC