- From: Norman Walsh <ndw@nwalsh.com>
- Date: Sat, 27 Dec 2008 11:16:38 -0500
- To: XProc Dev <xproc-dev@w3.org>
- Message-ID: <m2d4fdwq3d.fsf@nwalsh.com>
"David A. Lee" <dlee@calldei.com> writes: FYI: this is an area that the WG is actively discussing, so it's possible that some of what I say below will change. > What I mean is this. In an entity-expanding implementation, then I > would presume that p:identity WOULD expand entities, and there's > nothing in the specs to say it would have > to keep track of the base URI's for the elements it expanded. Ah. I think you're mistaken there. The base URI infoset property records the "URI used to retrieve the entity" per section 5.1 of RFC 2396. And XProc says, in 2.4.1: Except where the semantics of a step explicitly require changes, processors are required to preserve the information in the documents and fragments they manipulate. In particular, the information corresponding to the [Infoset] properties [attributes], [base URI], [children], [local name], [namespace name], [normalized value], [owner], and [parent] must be preserved. So I expect the base URI to be preserved through p:identity steps. > This would then make a test like add-xml-base-001 fail because the > p:identity would have lost where every element came from ... unless it > was a requirement that any expanded entity kept the base URI through > the entire pipeline which would be yet a more complex requirement then > I think you (or I) want to impose. Every element (and PI, though that's less commonly a concern) has a base URI property. Once set, it should be preserved. > I dont think it could be done > with adding xml:base attributes everywhere because it would break the > rest of the specs that assume, unless otherwise noted, that no new > attributes are added. > Thus the only way an implementation could preserve the base URI's > would be some 'secret back door channel' that preserves node identity > and base URI's throughout the pipeline. Yuck. You don't need a secret back door, most APIs provide the base URI of an element, you just need to make sure that gets preserved across steps. > So in conclusion, What I think is true ... > 1) The specs dont say anything one way or another about entity > expansion, although there's the implicit assumption that they probably > are expanded at any conceviable step. Yes. > And presumably, > since its not stated, dont have to keep track of where the expansion > came from (base uri). No. > 2) add-xml-base-001 is actually not testable as-is because there is no > requirement that implementations actually preserve the base URI when > they expand entities, or do or do not expand entities. No. > I certianly think the "intent" of add-xml-base-001 is correct, and I > will try to make my implementation match it, but I dont think its > testable, that is, I dont think it should strictly be considered a > failure if the step didnt expand entities, or somehow lost where the > expanded node came from. If your implementation doesn't expand entities, I think you could argue that you pass that test if the results you give are consistent with unexpanded entities. I don't agree that you're allowed to forget the base URI of elements. Be seeing you, norm -- Norman Walsh <ndw@nwalsh.com> | Next to knowing when to seize an http://nwalsh.com/ | opportunity, the most important thing | in life is to know when to forego an | advantage.--Benjamin Disraeli
Received on Saturday, 27 December 2008 16:17:18 UTC