- From: Michael Dyck <jmdyck@ibiblio.org>
- Date: Tue, 30 Jul 2002 01:59:53 -0400 (EDT)
- To: www-xml-linking-comments@w3.org
[I sent this two days ago, but it isn't in the archive, so I'm resending.]
--------------------------------------------------------------------------
XPointer Framework
W3C Working Draft 10 July 2002
1.2 Terminology
Definition: error
"results are undefined"
Not entirely. In fact, for the XPointer processor, the results are
quite well-defined: section 2 states that the processor must report
the error to the application. Beyond that, yes, results are
undefined.
Definition: failure
"failure of a pointer part"
This phrase isn't really defined. An XPointer processor identifies
a subresource of a resource by applying a pointer to it. The first
sentence of the definition says that if it's unable to do so, that's
a failure. (A failure of the pointer, one might say.) So the phrase
"failure of a pointer part" has not been defined.
I think it would be clearer to make "failure" a property (or result)
*only* of pointer parts. E.g., change
The inability of an XPointer processor to identify ...
to
The inability of an XPointer processor,
when evaluating a pointer part of a scheme-based pointer,
to identify ...
Moreover, you could replace the term "failure" with "pointer part
failure". And you could note that the term is typically invoked with
wording such as "the pointer part fails".
Yes, this would mean that you can no longer talk about "the failure
of a shorthand pointer", but there seems to be no need to. Where
section 3.2 says:
If no element is identified by this process, the Name fails and
the pointer is in error.
just delete:
the Name fails and
and you've lost no semantics.
Definition: namespace binding context
"A list of ... pairs of ... prefixes and ... URIs."
This description doesn't disallow a list that contains multiple
pairs with the same prefix. It would probably be better to use
XPath's terminology: a *mapping* from prefixes to URIs.
And actually, it's URI references, not URIs.
------------------------------------------------------------------------
2 Conformance
para 2 + 3
"normatively depend on"
It's not entirely clear what this means. I understand what it means
for a specification to normatively depend on another specification,
but this is talking about XPointer processors normatively depending
on certain procedures and information to do with the input that the
application passes to it. Thus, this seems to be more about the
conformance of the application than the XPointer processor.
para 3
"sufficient input about an XML resource to identify the following
information items and properties"
Isn't the infoset part of the resource? In which case, you shouldn't
need additional input about the resource. (And if the infoset isn't
part of the resource, what is?)
------------------------------------------------------------------------
3 Language and Processing
para 2
"a fragment identifier taken from the URI reference that was used to
access the resource"
It seems unnecessary to *require* that the XPointer processor's
input be derived from a URI reference. Yes, that's the expected
case, and the case that the XPointer language is explicitly intended
for, but it doesn't have to be the only case allowed. It's not like
the XPointer processor cares where its input comes from.
Instead of the quoted phrase, you could say
a string to be used as a pointer
which nicely parallels the phrasing in 3.1 para 1.
"the pointer extracted from the fragment identifier"
It's never stated what this extraction entails. I'm not sure that
it entails anything.
"the XPointer processor must reverse the encoding"
This appears to be at odds with section 2 para 2, which I took to
imply that the application must reverse the encoding.
Note that, if you accept that a XPointer processor's inputs might
come from somewhere other than a URI reference, only the application
will know whether any 2396/2732-decoding is necessary.
------------------------------------------------------------------------
3.1 Syntax
XPointer Framework Syntax
[3] schemebased ::= ptrpart (S?, ptrpart)*
Delete the comma.
Validity constraint
"The end of a pointer part is signaled by the right parenthesis ")"
character that is balanced with the left parenthesis "(" character that
began the part."
This sentence sounds more like a parsing rule than a syntax rule.
Does it express a constraint, or is it just a preamble to the real
constraint?
"If either a left or a right parenthesis occurs without being balanced
by its counterpart"
This wording suggests that a parenthesis could have a counterpart
and yet not be balanced by it. I suggest:
... without being balanced by a counterpart
or
... without having a balancing counterpart
or
... without having a counterpart to balance it
"Any other use of a circumflex is an error."
So escaping *balanced* parentheses is an error? I think this is a
bad idea. For instance, consider the ptrpart:
some-scheme(blah(")("))
The person who writes it may think, "Well, the parentheses in
blah(...)
are certainly balanced, but the parentheses in the string literal
")("
aren't, so I'd better circumflex-escape them." Thus:
some-scheme(blah("^)^("))
However, from the XPointer processor's point of view, the schemedata
blah(")(")
*does* have balanced parentheses. So the version with circumflexes
is supposedly an error? This seems unnecessarily restrictive.
You could avoid all these problems by dropping the validity constraint
and instead specifying the constraint in EBNF:
[6] schemedata ::=
( Char - [()^] | '^(' | '^)' | '^^' | '(' schemedata ')' )*
------------------------------------------------------------------------
3.2 Shorthand Pointer
para 1
"an XML-defined Name"
This could be misunderstood to mean something like "a name that has
been defined by an XML document somewhere", rather than "a token
that matches the 'Name' symbol defined in the XML specification".
I think it would be much clearer to say, in the Syntax section:
The symbols 'Name', 'S', and 'Char' are defined in the XML spec.
The symbol 'NCName' is defined in the XML Namespaces spec.
point 1 and 2
"with an [attributes] collection containing an attribute II, or
whose [children] collection contains an element II"
This might be a bit clearer if the two clauses had parallel
structure:
whose [attributes] collection contains an attribute II, or
whose [children] collection contains an element II
last para before the Note
"the Name fails and"
Delete. (See my comment on the definition of failure.)
------------------------------------------------------------------------
3.3 Scheme-Based Pointer
para 1
"XML-defined white space"
"XML-defined Char"
See my comment on 3.2 para 1.
para 2
"In the case of URI references referring to any resource"
I don't think it's necessary to bring up URI references here. You
could replace the quoted phrase with just:
For any resource
"this specification reserves all scheme names ..."
Could you be more concrete about what this means?
One possibility is that a conforming XPointer processor must (for
these media types) treat any scheme name other than those defined by
W3C XPointer scheme specs as an error. However, this would be rather
impolite, given that you're encouraging other XML-based media types
to use the XPointer framework in defining their own fragment
identifier languages: consider what happens when such a language is
*not* defined by a "W3C XPointer scheme specification", and content
negotiation causes the resource to be represented as text/xml,
rather than its usual text/something+xml. Suddenly the fragment
identifier doesn't work, even if it includes an xpointer() fallback.
Instead, perhaps the XPointer processor must treat it as a failure
of the pointer part. If that's the case, it would make more sense to
say it *after* the subsequent paragraph, which talks about
evaluating pointer parts.
para 3
"the scheme identifies no subresource"
Change "scheme" to "scheme data", I think.
"that part is consumed"
"Consumed"? An XPointer processor consumes pointer parts?
How about "that part is skipped"?
"If a scheme-based pointer has an error in its construction as a whole,
evaluation stops and pointer parts are not consumed."
Shouldn't the XPointer processor detect 'an error in the
construction as a whole' before starting evaluation?
Anyway, section 3.1 para 1 says: "If a string used as a pointer does
not adhere to the syntax defined in this section, it is an error."
Doesn't that cover this?
If it does, delete this sentence: section 3.1 para 1 is clearer.
If it doesn't, please clarify this sentence.
para 4
"A scheme-based pointer might contain characters that are not allowed in
a URI reference."
This is true of shorthand pointers as well, so this paragraph
probably belongs in section 3.1.
"by the time a pointer is fed as input ... into a URI resolver"
Unless a URI resolver resolves URI references (not just URIs), it
won't see fragment identifers.
------------------------------------------------------------------------
3.4 Namespace Binding Context
para 1
"interpreting element and attribute names' namespace prefixes"
This might be clearer as "interpreting the namespace prefixes
of element and attribute names".
para 2
"Pointer parts must not attempt to redefine the 'xml' prefix"
Given the "must not", wouldn't the attempt be a violation of the
framework? In which case, I'd expect at least a pointer part
failure, if not an error. Or do you only mean "should not"?
And if a pointer part binds 'xml' to its proper URI, does that
constitute "redefining" it?
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XPointer element() Scheme
W3C Working Draft 10 July 2002
1 Introduction
para 3
"The terms ..."
Actually, the term "application" isn't used at all in this spec.
"Note that errors defined by this specification are distinct from
XPointer Framework errors."
Well in that case, this spec *doesn't* use the term 'error' as
defined in the XPointer Framework spec, as claimed by the preceding
sentence.
But in fact, this spec doesn't need to use the word 'error'. Where
it says (section 3 para 2):
it is an element() scheme error and the pointer part fails
it could just say:
the pointer part fails
with no loss of semantics.
------------------------------------------------------------------------
2 Conformance
para 2
"normatively depend on sufficient input about ..."
See my comments on Framework section 2 paras 2+3.
------------------------------------------------------------------------
3 Language and Processing
para 2
"it is an element() scheme error and"
Delete. See my comment on section 1 para 3.
element() Scheme Syntax
[1] elementschemedata ::= (Name, childseq?) | childseq
Delete comma.
[2] childseq ::= ('/' [1-9] [0-9]* )+
Delete space before right paren.
para 6 ("A child sequence appearing alone...")
"The integer following the first slash represents the nth"
Insert 'n' after "integer"?
Change "represents" to "locates".
"which case"
Insert "in" before "which".
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XPointer xmlns() Scheme
W3C Working Draft 10 July 2002
1 Introduction
para 3
"The terms ..."
The term "application" isn't used at all in this spec either.
"Note that errors defined by this specification..."
Ditto my comment on the same sentence in the element() scheme spec.
------------------------------------------------------------------------
3 Language and Processing
para 2
"it is an xmlns() scheme error and"
Delete.
para 3
"S is as defined"
Change "S is" to "S and Char are".
para 4
"(NsURIRef)"
De-bold.
"and serves"
Insert "thus" after "and".
"If a pointer part defines a binding for a namespace prefix that already
has an entry in the namespace binding context, the new entry overrides
the old one."
This sentence should be moved to section 3.4 of the Framework spec.
para 7
"If the pointer part fails due to failure to conform to the syntax
described in this specification, it does not contribute an entry to the
namespace binding context."
This would be easier to state at the end of para 2: there, change
the pointer part fails.
to
the pointer part fails and does not contribute an entry to the
namespace binding context.
para 9
"The prefixes used in pointer parts ... the pointer part is addressing"
You switch from plural to singular.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-Michael Dyck
Received on Wednesday, 31 July 2002 05:53:49 UTC