> -----Original Message-----
> From: Peter B. West [mailto:[EMAIL PROTECTED]]
> Sent: September 30, 2002 11:24 PM
> To: [EMAIL PROTECTED]
> Subject: Re: <character>
> Arved Sandstrom wrote:
> >>-----Original Message-----
> >>From: Tony Graham [mailto:[EMAIL PROTECTED]]
> >>Peter B. West wrote at 30 Sep 2002 13:28:18 +1000:
> >> > Tony Graham wrote:
> >> > > [EMAIL PROTECTED] wrote at 27 Sep 2002 16:44:32 -0300:
> >> > > > That means "-", "#12235" , etc are characters, while
> >>"'1'" is not.
> >> > >
> >> > > ⿋ is a character reference. '#12235' is how you
> talk about a
> >> > > character's code point, although the hexadecimal representation is
> >> > > usually preferable.
> >> > >
> >> > > In XSL terms, "'1'" is a one-character string literal, but
> while you
> >> > > could claim that it is one character, there's no XSL
> >>conversion from a
> >> > > string to a character, so <fo:character character="'1'"/>
> >>should fail.
> >> >
> >> > Tony,
> >> >
> >> > I don't think this gets us out of difficulty. A casual inspection
> >>Forgive me, but I wasn't trying to get anybody out of any difficulty,
> >>I was just trying to keep the terminology accurate.
> >> > So how do I represent a character?
> >> >
> >> > To me, the cleanest, least ambiguous way is to represent a
> >> > attribute assignment value with "'<character>'" - a string literal of
> >> > length 1.
> >>Except that you know that that's not specified among the allowed
> >>The interesting thing is that 'character' doesn't appear in the
> >>productions in Section 5.9, Expressions, of the XSL Recommendation.
> >>Now there's a question for [EMAIL PROTECTED]!
> >>I think that you represent a character as a single character, e.g.,
> >>character="c", or as a numeric character reference, e.g.,
> > I agree with this last, after having digested everything.
> > Point is well taken that we have some points to nitpick with
> > mostly about disambiguating some of the language.
> Help me here. I must be missing something. What is it that you agree
> with? That the spec, as worded, leaves us with
> which amounts to the same thing?
Yes, this is what I agree with.
> If so, fair enough. Do you also agree that "c" is an NCName? And that
> is a parsing error?
Well, the production for NCName doesn't live in isolation, with reference to
http://www.w3.org/TR/REC-xml-names/#ns-decl. Yes, "c" fits the production,
but it's really an NCName when you have also declared the namespace.
Why is character="-" a parsing error? The XML Recommendation has at least
one example of an attribute value that contains a hyphen.
Maybe _I_ am missing something here. ;-)
> As far as I can see, the only immediate ways forward are to descend into
> the mire of context dependent parsing (which the editors have recently
> formally decided that we must do in respect of "format") or apply our
> own disambiguating condition. How are you intending to implement
By storing it as a Unicode value according to the XML Rec production
Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
It will depend on the implementation library. ICU for example has UChar and
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]