- From: Alex Miłowski <alex@milowski.com>
- Date: Wed, 10 Jun 2015 15:42:24 +0100
- To: XProc WG <public-xml-processing-model-wg@w3.org>
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