XPointer Second Last Call Disposition of Comments

Issue (editorial-lesch):

From Susan Lesch :

• place RFC 2119 key words under 1.2
• whitespace -> white spac
• update editors and date of XIS
• Deleting rowspan="1" colspan="1", and the thead and tbody elements from the tables in 4.1.3

Resolution (Member Only): Accepted, Editorial changes were agreed upon

This issue relates to XP102 in the Issues List. Mail back to commentor.

Issue (editorial-cmsmcq):

From Michael Sperberg-McQueen :

• wording for Section 3.3 Application conformance
• substitute the reference to IURI by the reference to the IRI Internet draft

Resolution (Member Only): Accepted, Editorial changes were agreed upon

This issue relates to XP106 in the Issues List. Mail back to commentor.

Issue (editorial-pollman):

From Mark Polman :

• In Section 5.3.4, why items 3 and 4 explicitly refer to NODE-points instead of just points?

Resolution (Member Only): Accepted, replace "node-point" with "point" in 3, 4 and 5

This issue relates to XP109 in the Issues List. Mail back to commentor.

Issue (editorial-dyck):

From Michael Dyck :

Michael provided a huge amount of comments on the second Last Call XPointer specification. A large amount of them were of editorial nature, and the Working Group focused on the technical suggestions made by Michael, letting the editors decides on points purely editorials. However the largest editorial point suggested were reviewed and decided by the Working Group:

1. In general, I think the spec would be ultimately clearer (especially to those who would introduce a new scheme) if it were structured as two specs, one that defined the general XPointer framework, and another that defined two schemes ('xpointer' and 'xmlns') that fit into that framework.
2. At the very least, it would be less confusing if the spec used different terms for the two things. (E.g., "XFragmentIdentifier" [XFragId] for the general framework, and "XLocator" or [the existing] "XPtrExpr" for the `xpointer'-specific expressions.)

Resolution (Member Only): 1/ Rejected, the working group did not reach consensus on splitting the specification, largely because the perceived cost of such a major structural change late in the process would outweight the benefits.

Resolution (Member Only): 2/ Rejected keep the terminology as is, Eve made an analysis and it seems we use XPointer uniformly in the spec to mean the full interpretation of XPointer.

This issue relates to XP110, XP118, XP119, XP120, in the Issues List. Mail back to commentor.

Issue (rfc3023-dyck):

From Michael Dyck :

• change [IETF I-D XMT] to [IETF RFC 3023]

Resolution (Member Only): Accepted, fixed in the document and Appendix A

This issue relates to XP110, XP111 and XP131 in the Issues List.

Issue (xp111-1-dyck):

From Michael Dyck :

• Introduction: 1st para: Section 5.2 (first bullet) makes it clear that "an application [may use] XPointers in another context than as a URI reference's fragment identifier", but it would be helpful if you said this in the introduction too.

Resolution (Member Only): Rejected, we were chartered only to define a fragment identifier syntax, the wording in section 5.2 were for completeness only.

This issue relates to XP111 in the Issues List.

Issue (xp113-1-dyck):

From Michael Dyck :

• 3.3 Application Conformance: I think it would be useful for the definition of application conformance and classes of errors, to define an "XPointer-processor" abstraction. The definition would go something like this: Given a resource (purportedly an XML document or external parsed entity) and a string (purportedly an XPointer), an XPointer-processor yields the subresource (location-set) identified by the XPointer or else an error. Then, for instance, instead of phrasing such as "Minimal conformance entails ..." (which avoids even a referent for the thing whose conformance is in question), one could say "An XPointer-processor is minimally conforming if it ..."

Resolution (Member Only): Accepted, add the definition of an XPointer-processor but add the fact that it is fully conformant.

This issue relates to XP113 in the Issues List.

Issue (xp114-k-dyck):

From Michael Dyck on the escaping section:

• "This escaping is removed when the XML document is parsed." "removed" sounds like it's removed from the file containing the XML doc. Maybe change to "undone" or "reversed".

Resolution (Member Only): Accepted, use "replace" since that's what is used in the XML-1.0 specification

This issue relates to XP114 in the Issues List.

Issue (xp116-c-dyck):

From Michael Dyck on the section 4.2:

• -- production [4]
      In 4.3 Schemes, you allow for the possibility that a future XML-based
      media type might choose to adopt the XPointer scheme mechanism, but
      define its own scheme instead of the "xpointer" scheme.  Consider the
      specification for the fragment identifier language for that media type:
      in defining the syntax, would it have to say something like "ignore
      the first two alternatives for XPtrPart"?
  
      It might be more convenient for future media types if XPointer said just
  
          [4] XPtrPart ::= Scheme '(' SchemeSpecificExpr ')'
  
      and then defined `xpointer' and `xmlns' as particular schemes, in the
      same way that future schemes will presumably have to be defined.

Resolution (Member Only): Rejected, we prefer to keep as is, we need to be able to point at 2 specific productions defined by this specification and prefer to minimize changes to the productions at this point.

This issue relates to XP116 in the Issues List.

Issue (xp117-b-dyck):

From Michael Dyck on the section 4.3:

• "reserves all others"
      It's not clear what this means.
  
      Is any other scheme a syntax error? A resource error? Or is the
      XPointer-processor required to treat it as an unknown scheme (and thus
      fail that part)? Or something else?
  
      What about when the XPointer is used in a context other than as the
      fragment identifier of a URI reference? Then there isn't necessarily a
      media type involved.

Resolution (Member Only): Accepted, If there is a binding that says an XPointer processor is supposed to handle this XPointer and it doesn't recognize a scheme, the right failure point seems to be on the scheme. This would be an XPointer part failure, and it should continue to the next part (if any). We need to clarify that. On his second point: We don't need to specify anything about occasions when it's used in a context not covered by this spec.

This issue relates to XP117 in the Issues List.

Issue (xp118-f-dyck):

From Michael Dyck on the section 5 the changes relative to XPath:

• you missed the range and range-inside functions.

Resolution (Member Only): Accepted, add a 7th bullet with "The functions range and range-inside, to address the covering range of location sets."

This issue relates to XP118 in the Issues List.

Issue (xp122-b-dyck):

From Michael Dyck on the section 5.3.1 :

• "preceding any individual character"
      Insert "or following" after "preceding".

Resolution (Member Only): Accepted, on the theory that keeping an asymmetric definition is awkward for implementation, and also add information about doing an equality test.

This issue relates to XP122 in the Issues List.

Issue (xp122-e-dyck):

From Michael Dyck on the section 5.3.1 :

• But these two sentences don't really belong here (the content of its
      axes are not the defining properties of a point), and anyway, they're
      redundant given the 2nd and 3rd bullets. Delete them.

Resolution (Member Only): Accepted, delete the third-to-last and second-to-last sentences in the first paragraph of 5.3.1.

This issue relates to XP122 in the Issues List.

Issue (xp125-d-dyck):

From Michael Dyck on the section 5.3.5 :

• "the last of those [attribute or namespace] nodes"
      Append:
          "in document order. (Note that this is implementation-dependent.)"

Resolution (Member Only): Accepted, right add it

This issue relates to XP125 in the Issues List.

Issue (xp125-g-dyck):

From Michael Dyck on the section 5.3.5 :

• The rest of the section is muddled. Look at it this way: you have to define
  an ordering for every combination of node, point, and range:
      {node, node}   - defined by XPath
      {node, point}  - 4th para, using terms "before" and "after"
      {node, range}  - 5th para, using the term "relative order"
      {point, point} - 6th para, using the term "document order"
      {point, range} - missed
      {range, range} - 7th para, using the term "before"
  So you missed the combination of point and range, and you used lots of
  different terms to do it. XPath mostly just defines the "before" relation.

Resolution (Member Only): Accepted, refactor the paragraph as suggested, for comparing a point to a range we compare the point to the start of the range which is one of the defined existing comparisons.

This issue relates to XP125 in the Issues List.

Issue (xp126-d-dyck):

From Michael Dyck on the section 5.4 and 5.4.1 :

• -- 4th para
  "for each of the nodes in the current node list"
      "the current node list" is an undefined term. If we allow that readers
      will understand what you mean, you should still change "nodes" to
      "locations" and "node list" to "location list".

Resolution (Member Only): Accepted, change approved

This issue relates to XP126 in the Issues List.

Issue (xp127-d-dyck):

From Michael Dyck on the section 5.4.2 string-range() :

• Also, it's not a very good definition.
      You could say: "A string range is a range whose start point and end
      point are both character-points."

Resolution (Member Only): Accepted, change approved

This issue relates to XP127 in the Issues List.

Issue (xp127-d-dyck):

From Michael Dyck on the section 5.4.2 string-range() :

• generalize "document" to "document or external parsed
  entity, as appropriate".

Resolution (Member Only): Accepted, change approved

This issue relates to XP127 in the Issues List.

Issue (xp128-a-dyck):

From Michael Dyck on the section 5.4.3.2 range-inside() :

• -- 1st para
  "If x is a range location or a point, the x is added to the result..."
      But if x is a point, then you'd be adding a point to the result, and you
      just said that the function returns ranges.  Instead, you presumably
      want to add the collapsed range at that point.

Resolution (Member Only): Accepted, change approved

This issue relates to XP128 in the Issues List.

Issue (xp128-b-dyck):

From Michael Dyck on the section 5.4.3.2 range-inside() :

• "If x is not a range location"
      -> "If x is a node"

Resolution (Member Only): Accepted, this need change, but use "otherwise" instead.

This issue relates to XP128 in the Issues List.

Issue (locationset-nodelist):

From Andrew Watt raised a difference between XPath node-sets and XPointer location-sets :

• XPointer says a location set is ordered
• XPath says node-sets are unordered

Resolution (Member Only): Accepted, the definition of location-set is changed to: "An unordered list of locations, such as produced by an XPointer expression. This corresponds to the node-set that is produced by XPath expressions, except for the generalization to include points and ranges. Just as for a node-set, a location-set is treated as having a specific order depending on the axis that is operating on it. However, this ordering depends on XPointer's extended notion of document order as defined in Section 5.3.5, rather than XPath's original notion of document order."

This issue relates to XP104 in the Issues List. Mail back to commentor.

Issue (additional-schemes):

From Michael Sperberg-McQueen suggesting to extend XPointer to allow additional schemes for text/xml and application/xml:

• "XML Schema documents are likely to be shipped as text/xml or application/xml (the XML Schema spec is to be agnostic on this point), but users would, I think, benefit from a scheme allowing the simple identification of arbitrary schema constructs by reference to their nature and local name, without reference to the element structure of the schema document in which they happen to be declared."

Resolution (Member Only): Rejected, Eve gave an answer to Michael on this issue, and both the WG and Michael accepted it.

This issue relates to XP105 in the Issues List.

Issue (namespace-thomson):

From Henry Thomson suggested to provide a namespace for XPointer:

• "I agree that it's not immediately obvious that there's any need for a namespace URI in the short term, but it wouldn't hurt to establish it now for future use, e.g. to have an XML Schema with a simple type definition for the XPointer subset of xs:uriReference."

Resolution (Member Only): Accepted, We will usee the following namespace http://www.w3.org/2001/05/XPointer

This issue relates to XP108 in the Issues List.

Issue (axis-pollman):

From Mark Polman raised a few issues with section 5.3.4 where "point" and "range" are introduced:

1. does the associated tests ever return a non-empty location set?
2. about the definition of siblings axis for points
3. about the semantics of "following" and "preceding"

Resolution (Member Only): 1/ Accepted, section 5.3.4 will be reworded the new wording is defined in the Issue List XP109

Resolution (Member Only): 2/ Accepted, redefine precisely the various axis for points, add a graphic to make the relationship between sibling points clear.

Resolution (Member Only): 3/ Accepted, the "following" and "preceding" axes are added (in the first bullet of the list) as empty.

This issue relates to XP109 in the Issues List.

Issue (xp110-dyck):

From Michael Dyck :

• Status of This Document: 4th para: "This document is intended to be taken in conjunction with [x], in order for that document to officially designate XPointer ..." Awkward construction. How about just: "It is intended that [x] officially designate XPointer ..."

Resolution (Member Only): Accepted, change the beginning of the sentence to "It is intended that an IETF registration document eventually designate XPointer ... "

This issue relates to XP110 in the Issues List.

Issue (xp111-2-dyck):

From Michael Dyck :

• Introduction: 1st para: -- 4th para, 3rd bullet: "in URI references as fragment identifiers" -> "as fragment identifiers in URI references"

Resolution (Member Only): Accepted, reword the entire third bullet as "Be used in URI references to address into resources" and move it to be the first bullet.

This issue relates to XP111 in the Issues List.

Issue (xp113-2-dyck):

From Michael Dyck :

• "routing XPointer parts with particular schemes to an application that can evaluate those parts" This wording seems fairly implementation-specific. From the point of view of someone judging the conformance of XPointer-handling software, whether that software routes parts to other applications is immaterial.

Resolution (Member Only): Rejected, we don't see it as a point of confusion since it describes an abstract model.

This issue relates to XP113 in the Issues List.

Issue (xp113-3-dyck):

From Michael Dyck :

• So, as long as it handles bare names, an XPointer-processor that yields a sub-resource error for every FullXPtr is minimally conforming, since it can claim not to understand any schemes. In which case, why not just say that minimal conformance only entails interpretation of bare names?

Resolution (Member Only): Rejected, this is a divergence in interpretation of what is an XPointer processor, it must understand the xptr scheme

This issue relates to XP113 in the Issues List.

Issue (xp114-e-dyck):

From Michael Dyck :

• 4.1.1 Escaping Contexts: You should point out that an XPointer can occur in many other contexts (a string-literal in a Java program, a comment in a LaTeX document, etc.) and these will generally have their own escaping requirements. The ones outlined in this section are just the most common. This spec is normative only for context A. In all other cases, the specification that governs the context is the normative reference for the necessary escaping. Also, an XPointer may appear in many contexts at once (e.g., an XPointer in a URI reference in an XML document in a Java string-literal), but these are always nested in a particular order, and it is the nesting order that determines the order in which the escaping and unescaping is done. (The most deeply-nested context does the first escaping and the last unescaping.)

Resolution (Member Only): Accepted, add a single sentence in the paragraph before 4.1.2 "an XPointer can occur in many other contexts and these will generally have their own escaping requirements."

This issue relates to XP114 in the Issues List.

Issue (xp114-h-dyck):

From Michael Dyck on the escaping section:

• B: "Escaping of reserved URI characters" This heading is not very appropriate, since the section only considers the escaping of one URI-reserved character, the percent sign.
• C: "If an XPointer appears in a URI reference or IURI reference in an XML document" Delete "in a URI reference or IURI reference": it is immaterial to the need for escaping. You may wish to change it to "in the character data of an XML document", since this escaping wouldn't be necessary if an XPointer appeared in, for instance, a comment in an XML document. (Although in that context, you *would* need to somehow escape any occurrences of "--".)

Resolution (Member Only): Rejected, this section was designed closely with the I18N working groups and is used as reference in other specs, we prefer not to change it at this point.

This issue relates to XP114 in the Issues List.

Issue (xp114-o-dyck):

From Michael Dyck on the escaping section:

• -- last para:
  "in the reverse order"
      The reverse of what? You haven't specified the "forward" order. (But
      I've given some wording above that does.)
  
  "If the result [of undoing the encodings and escapings] does not conform to
  the syntactic rules for XPointers in this specification, a syntax error
  results."
      But if you undo escaping A, the result may have unescaped unbalanced
      parentheses, which are not permitted by the "Parenthesis escaping" VC.
      And if you think that "the syntactic rules" does not include VCs, note
      that the bare EBNF disallows unbalanced parentheses, escaped or not.
      So either way, a syntax error would supposedly result, which is not what
      you want.
      I suppose you could say "If the result, before undoing escaping A, ..."
      but that's pretty ugly. If you adopt the idea of an XPointer-processor,
      you could say something like (very roughly):
          The XPointer-processor handles undoing A. All other escaping is
          undone (in reverse order of application) outside the processor.
          If the result (passed to the processor) does not conform ...
          the processor yields a syntax error.

Resolution (Member Only): Accepted, the change and his wording since we also included the definition of an XPointer processor:

The XPointer-processor handles undoing A. All other escaping is undone (in reverse order of application) outside the processor. If the result (passed to the processor) does not conform ... the processor yields a syntax error.

This issue relates to XP114 in the Issues List.

Issue (xp116-g-dyck):

From Michael Dyck on the section 4.2:

• "Any other use of a circumflex results in a syntax error."
      So escaping *balanced* parentheses is invalid?
      (Software that generates xpointers might find it easier to escape *all*
      parentheses rather than figure out which ones are unbalanced.)

Resolution (Member Only): Rejected, we prefer to keep as is, escaping all parenthesis in general is not possible, they are needed for scheme boundary detection, only paranteses within string values may need to be escaped in practice.

This issue relates to XP116 in the Issues List.

Issue (xp116-l-dyck):

From Michael Dyck on the section 4.2:

• 4.2.2 Bare Names
  -- 1st para
  "a location step using the id() function"
      Syntactically, "id()" isn't a location step (i.e., Step), it's a
      FilterExpr.

Resolution (Member Only): Accepted, change the first sentence to "A bare name stands for the same name provided as the argument of id()."

This issue relates to XP116 in the Issues List.

Issue (xp117-h-dyck):

From Michael Dyck on the section 4.3:

• -- 4th bullet
  "If the scheme being interpreted is xpointer:"
      -> "If the part's scheme is xpointer:"
      Minimal conformance does not require interpretation of the 'xpointer'
      scheme, so this bullet does not belong here.
  
      Moreover, I disagree that these conditions should be grounds for a part
      to fail. (But I'll discuss that later.)
  
      Lastly, what does it mean for a point to be "of type attribute or
      namespace"?
          

Resolution (Member Only): Accepted, we should break out the fourth bullet entirely into its own paragraph just below the list, and head it up by saying "Full conformance additionally requires the following part failure handling:".

This issue relates to XP117 in the Issues List.

Issue (xp117-k-dyck):

From Michael Dyck on the section 4.3:

• "If a syntax error is detected in any part or in the construction of the
  XPointer as a whole, evaluation stops and additional parts are not consumed"
      If there were a syntax error in the construction of the XPointer as a
      whole, then according to section 3.4, the application should not have
      attempted to evaluate it in the first place. (But apparently it did,
      since it must now stop evaluation.)
  
      Presumably, the processor is not required to detect syntax errors in the
      SchemeSpecificExpr of any part whose Scheme it doesn't understand.
  
      Say there is a syntax error in the SchemeSpecificExpr of a part whose
      Scheme the processor *does* understand, but that part occurs after
      another part that would succeed if evaluated. e.g., something like:
  
          xpointer(/)4Dgrafix-xml("unterminated literal)
  
      Is the processor required to detect the later syntax error (and thus
      stop with an error) before evaluating the first part, or is it required
      to detect scheme-specific syntax errors only if and when it gets to the
      part that contains the error?  (In a "routing" implementation, you
      probably want the latter.)

Resolution (Member Only): Rejected, The left-to-right nature of evaluation means that the later syntax error in his example wouldn't be caught. Does the existing wording need to be changed, though? We decided that it's redundant, but not false, so we're going to keep it.

This issue relates to XP117 in the Issues List.

Issue (xp119-b-dyck):

From Michael Dyck on the section 5 the changes relative to XPath:

• Actually, the context must also contain properties for the locations
              that the origin() and here() functions return.

Resolution (Member Only): Accepted, add that "the context must also contain properties for the locations that the origin() and here() functions return."

This issue relates to XP119 in the Issues List.

Issue (xp119-c-dyck):

From Michael Dyck on the section 5 the changes relative to XPath:

• Append "or external parsed entity".

Resolution (Member Only): Accepted, add mention of "or external entity."

This issue relates to XP119 in the Issues List.

Issue (xp120-c-dyck):

From Michael Dyck on the section 5.2.1 :

• This suggests that if the XPointer appeared in an XML document that
      *did* have a declaration of the namespace prefix x, it *wouldn't* result
      in a sub-resource error. I think this is incorrect, since the first para
      doesn't mention anything about namespace declarations leaking from the
      containing document into the XPointer evaluation context.
      So delete "appearing ... prefix x)".

Resolution (Member Only): Accepted, this is an old feature of the example that needs to be fixed. Delete the text "appearing in a non-XML document (or in an XML document with no declaration of the namespace prefix x)". Even though the example is now overkill (because it shows the same prefix attached to two namespaces when just one would have done), we'll keep it.

This issue relates to XP120 in the Issues List.

Issue (xp121-a-dyck):

From Michael Dyck on the section 5.3 :

• -- Note
  "DOM Level 2, which is based on UTF-16 units"
      It would be more accurate to say that DOMStrings encode UCS characters
      using UTF-16, and the DOM indexes into them using 16-bit units. Thus,
      one UCS character results in one or two 16-bit units. 
  
  "XPath and XPointer are based on UCS characters"
      In effect, implementations must behave as if they encode UCS characters
      using UTF-32 (UCS-4).
  
  "a sequence which in DOM counts as two characters might count in XPointer
  as one character"
      This is a misuse of the term "character", but I'm not sure what the
      proper term is. Something like "string indexing unit"?

Resolution (Member Only): Rejected, this is Michael Notes on a point which is not directly part of our specification, keep as is

This issue relates to XP121 in the Issues List.

Issue (xp122-g-dyck):

From Michael Dyck on the section 5.3.1 :

• Are "preceding" and "following" empty too?

Resolution (Member Only): Accepted, drop "preceding" and "following" axis i.e. they are empty for points

This issue relates to XP122 in the Issues List.

Issue (xp122-h-dyck):

From Michael Dyck on the section 5.3.1 :

• Presumably the "descendant-or-self" axis also contains the point itself.

Resolution (Member Only): Accepted, right add it

This issue relates to XP122 in the Issues List.

Issue (xp122-i-dyck):

From Michael Dyck on the section 5.3.1 :

• Does "ancestor-or-self" contain the point itself and the contents of the "ancestor" axis?

Resolution (Member Only): Accepted, right add it

This issue relates to XP122 in the Issues List.

Issue (xp123-e-dyck):

From Michael Dyck on the section 5.3.2 :

• replace the whole para with this:
  
          The string-value of a range consists of the characters that are in
          text nodes and that are between the start and end points of the
          range.

Resolution (Member Only): Accepted, the fact that the whole section needed some cleanup. All the axis for a a range are empty excepted *self which are the range itself. Add a note about start-point() or end-point() should be used as intermediary step for doing axis computation from a range .

This issue relates to XP123 in the Issues List.

Issue (xp125-i-dyck):

From Michael Dyck on the section 5.3.5 :

• "If the immediately preceding nodes of the two points are the same, then
  either the points are the same or they are both character-points with the
  same container node"
      This is not true. For instance, in "<e>foo<e>", consider:
      (1) the node-point whose container node is the <e> element node, and
          whose index is 1 (the point after the text node); and
      (2) any character-point whose container node is the text node.
      For both points, the immediately preceding node is the text node, but
      they are not the same point, nor are they character-points with the same
      container node.

Resolution (Member Only): Accepted, node point and character points are relatively differents. We want to explain the document order to points. It won't fit into a single sentence, though. This part will be reworded and a graphic will be added.

This issue relates to XP125 in the Issues List.

Issue (xp126-b-dyck):

From Michael Dyck on the section 5.4 and 5.4.1 :

• -- 1st para
  "For each location in the context,"
      This is misleading; there *is* only one location in the context. Delete.
      (You could say "For the location in the context" or "Given the location
      in the context" or just "Given the context", but they're all implied by
      the definition of evaluation context -- no other XPointer/XPath function
      is defined with such a phrase.)

  and

  "the location found by evaluating the expression argument with respect to
  that context location"
      It's not the function's job to evaluate the expression(s) that appear in
      a call to the function. XPath semantics say that the arguments are
      evaluated before the function is called, and the results are passed to
      the function.
      Change to:
          "the location that is the only member of the location-set argument".
      You could add:
          "(Note that [in accordance with XPath semantics] the Argument in the
          FunctionCall will have been evaluated with respect to the same
          context as the FunctionCall itself.)"
  
  There should be a sentence saying that it's some kind of error if the
  location-set argument doesn't contain a single location (isn't a singleton).

Resolution (Member Only): Rejected, this wording was the result of a lot of discussions during the first Last Call and CR stage, the wording suggested potentially change the semantic of the existing definition, keep as is.

This issue relates to XP126 in the Issues List.

Issue (xp127-e-dyck):

From Michael Dyck on the section 5.4.2 string-range() :

• -- 3rd para
  
  "If the string argument is not found in the string-value of the location,
  ... the XPointer part in which the function appears fails."
      I'm pretty sure you don't want this. For instance, consider
          string-range(//title, "Thomas Pynchon")
      If *any* <title> element doesn't contain "Thomas Pynchon", the string
      argument will not be found in the string-value of that location, and so
      (according to the above rule) the part will fail.

Resolution (Member Only): Accepted, change string-range(), if the string argument is not found in the string-value of the location, no range is added to the location set result (instead of generating an XPointer part error).

This issue relates to XP127 in the Issues List.

Issue (xp129-d-dyck):

From Michael Dyck on the section 5.4.3.3 start-point() and 5.4.3.4 end-point():

• "If x is of type attribute or namespace, the XPointer part in which the
  function appears fails."
      I'm mystified: why is it so wrong to ask for the start-point (or
      end-point) of an attribute or namespace location? Why can't these
      functions treat such locations just like text, comment, and
      processing instruction locations? That's what range-inside does.
      In fact, if someone really wanted to write
          start-point(@foo)
      they could get around start-point's dislike of attribute locations just
      by writing
          start-point(range-inside(@foo))
      If the latter expression isn't erroneous, why is the former?
  
      In fact, it seems to me that:
          start-point(range-inside(L)) = start-point(L) for all locations L
      would be a useful identity. (Ditto end-point.) Not that you'd have to
      say so explicitly; but you could, for instance, define range-inside(L)
      as the range from start-point(L) to end-point(L), roughly speaking.

Resolution (Member Only): Rejected, keep as is we would prefer to not add complexity at this point

This issue relates to XP129 in the Issues List.

Issue (xp131-a-dyck):

From Michael Dyck remaining comments :

• 5.5 Root Node Children
  
  It isn't just a change to the children that the root node can have -- it's
  the very fact that an external parsed entity even *has* a data model.

Resolution (Member Only): Rejected, this is an old issue already discussed, keep as is.

This issue relates to XP131 in the Issues List.

2.4 Patent Issues

Issue (patent-watt):

From Andrew Watt :

• suggested to change the wording in the status of the document to not imply that Sun Microsystem's patent actually covers XPointer

Resolution (Member Only): Accepted, the working group recommends to change it to something like "Certain parts of XPointer may be affected by a technology patent held by Sun Microsystems.", but ultimately the sentence is in the Status so it's under the W3C staff responsability to make this change.

This issue relates to XP103 in the Issues List. Mail back to commentor.

Issue (patent-carr):

From Wayne Carr suggested to wait for CR until the Patent situation is cleared up:

• "We are very concerned about the IPR situation in XPointer. We don't think precedent should be set for the type of terms that are being required for IPR on XPointer. The group should attempt to work around the patent before proceeding to Candidate Recommendation."

Resolution (Member Only): Rejected, unfortunately it's not workable at the XML Linking Working Group level. This need to be handled at the Company and W3C level, this may influence the way W3C members will vote at the Proposed Recommendation stage or even whether Proposed Recommendation is granted. The working group has not resolved the issue and defer the treatment of this issue to the next layer of processing.

This issue relates to XP107 in the Issues List. Mail back to commentor.