- From: Alex Milowski <alex@milowski.org>
- Date: Wed, 9 Jan 2008 17:42:49 -0800
- To: "XProc WG" <public-xml-processing-model-wg@w3.org>
On 11/15/07, Henry S. Thompson <ht@inf.ed.ac.uk> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > I propose we add the following to handle this: > > > > * In section 5.10 p:import, we need to define the resolved > > location based on the 'href' attribute. The 'href' attribute must > > be resolved against the base URI of the p:import element. The > > resulting URI is the "resolved location" of the import. > > Hmm, not quite -- I think the "resolved location" is whatever your URI > library comes back with as the location, so that redirects and conneg > are allowed for. If your library processor follows redirects, it will follow them every time. I still strongly believe that the resolved location should be the result of resolving the 'href' attribute against the base URI. That is a consistent and well-defined algorithm. We shouldn't change that as a result of some protocol interaction whose results may be temporary. > > So I think we agreed that this has to be expanded and changed a bit, > along the following lines: > > 1) Do a 'minimal load' of every pipeline and pipeline library > document, by processing all p:imports, recording their resolved > locations, and declining to load anything twice; > > 2) Determine the type names *defined for export* by each top-level > scope == top-level pipeline or pipeline library == entry in the > resolved location table and every, as follows (see [1]): > > a) The pipeline name itself, if the scope is a pipeline; > b) The step types and pipelines defined therein, if the scope is a > library. > > 3) Associate with every pipeline and library the resolved location of > all its imports, and from any of those which are libraries, the > resolved locations of all _their_ top-level imports, recursively. > That is, the transitive closure of p:import, _not_ descending into > p:pipeline. > > 4) Determine the type names visible within each library, as follows: > > a) The step types and pipelines defined locally within the library; > c) The types _defined for export_ by all the resolved locations > identified for the library in (3) above. > > 5) Determine the type names visible (in addition to the builtins) in > each pipeline, as follows (see [1]): > > a) The pipeline name itself; > b) The step types defined locally within the pipeline; > c) The types _defined for export_ by all the resolved locations > identified for the pipeline in (3) above; > d) The type names visible within its enclosing library, if it's in > one. I agree with the above. > This does more work than strictly necessary, and is liable to > optimisation in the absence of circularity, but it's simpler to state > w/o optimisation. > > On balance, I think this is too detailed to fit well in the > spec. itself. I think what we need in the spec., pbly in section 3.2, > is [1] and something like this: > > Circular and re-entrant chains of p:import are not errors, and > implementations MUST take the necessary steps, based on testing > string equality of the actual URIs involved (that is, after > absolutization and redirection, if any), to avoid infinite loops or > spurious duplicate-definition errors. Appendix XXX provides > high-level description of one algorithm which does this. > > and then put the above 5-step story in (non-normative) Appendix XXX. I agree. Let's put this in an appendix and see what people think. -- --Alex Milowski "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 Thursday, 10 January 2008 01:42:54 UTC