RE: Comments on Concepts editors' draft 2003-06-19

I am unlikely to respond in detail before the telecon, just picking up on
5.1 comments:

> > Section 5, para 5, editorial suggestion.
> >
> > "A datatype is identified by one or more URI references."
> >
> > While strictly correct, I'm not sure that "one or more" adds any
> > important information, reads awkwardly and possibly confusingly.  I
> > would be inclined to delete it.
> >
> > ...

discuss at telecon ...

> > Section 5.1, "The lexical space", final bullet, maybe serious.
> >
> > The phrase "start and end element" seems wrong to me.  I think this
> > should be just "element" or "start and end element tags".
> >
> > ...
> >

This is in response to an editorial comment from XML Schema WG; I will
double check (their comment was about the term "root element tag")

> > Section 5.1, lexical-to-value mapping, muddled?
> >
> > I don't understand this, and it seems over-complicated.
> >
> > My understanding is that we decided that XML literals are self denoting
> > like plain literals, hence the lexical mapping maps the lexical
> value to
> > itself.  The surrounding description of the lexical space and the value
> > space, which are both canonical XML, supports this view.
> >
> > ...

discuss at telecon

"maps a string to the corresponding exclusive Canonical XML "

click though on exclusive canonical XML to
"XML that is in exclusive canonical form"
look up to see that

"The exclusive canonical form of a document subset is a physical
representation of the XPath node-set, as an octet sequence, produced by the
method described in this specification"

i.e. the value space of XMLLiteral is a set of octet sequences whereas the
lexical space is a set of strings (character) sequences.

I pass on whether { 173 } is both a character sequence and an octet
sequence.
ditto for {} (which is exclusive canonical XML if it is an octet sequence)




> >
> > Section 6.4, 3rd para (just after numbered list), editorial.
> >
> > I think this description of disallowed octets could be confusing.
> >
> > For example, the current work-in-progress draft of RFC2396bis [1] uses
> > '['...']' in IPv6 literals in the 'authority' component of a URI, and
> > requires them to be escaped everywhere else.
> >
> > I think the problem stems from the dual purpose of escaping in URIs (to
> > protect special characters from interpretation, and to include
> otherwise
> > disallowed characters in a URI.  I'm not sure how to fix this, other
> > than to suggest maybe "less is more";  e.g.
> >
> > "The disallowed octets that must be %-escaped include all those that do
> > not correspond to US-ASCII characters, and any others that would
> > otherwise be interpreted inappropriately according to the URI
> > specification and URI scheme specification concerned."
> >
> > [1] http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.html
> >
> > ...
> >


Hmmm ... I think that's trying to jump ahead of rfc2396bis - and basically
given the state of the TAG issue IRI Everywhere, we should really only be
treading water.

Received on Friday, 20 June 2003 09:23:55 UTC