- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Fri, 31 Jul 2009 15:43:18 +0100
- To: <Toman_Vojtech@emc.com>
- Cc: <public-xml-processing-model-comments@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vojtech writes: > [a question about Appendix G, Handling Circular and Re-entrant > Library Imports] Hmm. That algorithm [1] is at best misleading, if not downright broken. In step (4), it says: . . . R := union of (R,r[0]) . . . If N(U,P) contains duplicates, then the same step name is declared in different resources (which is an error). . . . If S(U) contains any duplicates, then the same step name is declared in different resources (which is an error). The first 'If...' is incoherent, since N(U,P) is a pair, so 'containing duplicates' doesn't make any sense. I think it should just be removed. The second 'If...' will, however, never fire, embarassingly, because the assignment above, being a union (and R being _set_), will by definition merge duplicates! Corrected version of (3) -- (5) follows: 3. Associated with every resource URI a list of step types declared within and a list of the "top level" imported resource URI values (i.e. the base URI of the resolved resource for each p:import element in the library or pipeline). This is effectively two maps: D: {uri} -> {bag of step declarations} I: {uri} -> {set of uris} 4. For any resource, we define a recursive map: N: ({uri}, {set of uris}} -> ({bag of step declarations},{set of uris}) N(U,P) := let R := D(U) for each k in I(U) if k not in P P:= P + k let r:= N(k,P) R:= R + r[0] P:= r[1] return (R,P) 5. For any resource, the bag of types recursively defined therein is: S: {uri} -> {bag of step declarations} S(U) := N(U,{})[0] If S(U) contains any duplicates, then the same step name is declared in different resources (which is an error). > The algorithm in the section "Handling Circular and Re-entrant Library > Imports" does not seem to take into account the fact that p:declare-step > and p:pipeline can contain import statements as well. > Since the algorithm is primarily URI-based, the spec should probably say > something about how to represent the nested p:declare-step/p:pipeline as > URIs, at least conceptually. I _think_ we said that import processing could be lazy, didn't we? That is, only top-level imports get followed automatically -- nested ones only get called if their embedding pipeline gets used. Furthermore, and arguably more important, nested imports are scoped to the pipeline which embeds them: "An import statement loads the specified IRI and makes any pipelines declared within it available to the current pipeline." OTOH we have (in 3.2 Scoping of Names [2]) "The scope of the names of the step types is the pipeline in which they are declared, including any declarations imported from libraries via p:import. Nested pipelines inherit the step types in scope for their parent." So, I think we need to add the following to Appendix G: [proving harder than I thought. I think the whole appendix needs to be rethought. I'm working on it. . .] ht [1] http://www.w3.org/XML/XProc/docs/langspec.html#handling-imports [2] http://www.w3.org/XML/XProc/docs/langspec.html#scoping - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFKcwMGkjnJixAXWBoRApQTAJ0flJtvQC0epqCZ5tIgnMOYeuHMKwCfSeA0 HcWJ7lXdQ8rPuzzkuX9wx3U= =5uyK -----END PGP SIGNATURE-----
Received on Friday, 31 July 2009 14:43:56 UTC