RE: Con Call and XPointer/XPath

At 09:30 99/09/14 -0700, John Boyer wrote:
 ><John>
 >The RD says that partial document is a requirement, and an implied
 >requirement is security, but since we also have certain timeline
 >requirements, so what you're saying is that some of the requirements will
 >not be required in order to meet the timelines.  We could do partial
 >document, but not with high security, or we could do high security, but
drop
 >partial document, or we could do both but possibly at the cost of the
 >timeline.
 ></John>

Its all a balancing act. My philosophy is to always (or as soon as possible)
have a spec that can be implemented but with lots of simple options,
defaults and stubs in there. Sort of like ship early and often.

 ><John>
 >Why remove it when it can be demonstrated that we simply need a way to
 >process and, or and not logic, and keep track of where in a tree we are,
all
 >of which are similar to algorithms studied in second or third semester data
 >structures.  We all do the little infix math processors and trees at around
 >that time.
 ></John>

Again, my default is to not justify removal, but justify inclusion.
 ><John>
 >Secondly, I think it is fairly well understood.  XPath doesn't come out and
 >say so because I think they assumed it was obvious, but the entity refs
 >should obviously be resolved during the parsing of the document, so the
 >xpointer would refer to the second <e/>.

I'd agree with that, so it does implicitly get filtered through InfoSet/DOM.
Doing a string based perl XPtr locator would not work (or you have to
specify the c14n with it as well.)

_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/