RE: Charmod review

* REVISED VERSION *
In particular note the NEW BIT which is stuff that arised from the e-mail exchange last week but
didn't get discussed at the telecon.
If people don't like it, an alternative is to delete that comment, and possibly put sections 1,2
back into the general endorsement part.

A question for the group, one of the conformance requirements is that "Every W3C specification MUST
specify that implementations MUST conform to the requirements applicable to software,".
While this is not unreasonable it jars with the RDF recs that we are writing in that we do not talk
about how to implement RDF hardly at all. If we were aiming at charmod conformance we could stick a
charmod conformance section in, that would say that amongst other things; but it would be a little
strange. Can anyone draft a comment that captures this anxiety; or am I just being overly nervous.

Perhaps someone better with words than me can combine this worry with that expressed in the NEW BIT
and the UNCHANGED comment on section 3.5 - there is this common theme that charmod assumes a certain
sort of recommendation which we are not.

................


> =========
>
> The RDF Core WG has feedback concerning the following sections
> of charmod:
>
> 1. Introduction
> 2. Conformance
> 3.4 Strings
> 3.5 Reference Processing Model
> 4. Early Uniform Normalization
> 6. String Identity Matching
> 8. Characeter Encoding in URI References
> 9. Referencing the Unicode Standard
> A.2 Other References
> C. Composing Characters
> D. Resources for Normalization
>
>

RDF Core makes no comments on the other sections.

*** MODIFIED, (TONED DOWN) ***
For the sections 3.4, 4, 6, 9, C, D
RDF Core endorses the last call working draft.
We have found earlier drafts helpful in identifying how best to meet our
responsibilities to RDF users world wide.
(However, we do not intend to address all the requirements of these sections in the version of the
RDF recommendations currently in working draft).

*** NEW BIT ***
Concerning sections 1 and 2 RDF Core is concerned that the scope of charmod is overly broad.
In particular, there appears to be no acknowledgement that some languages being defined by W3C
working groups may not be intended as web languages and hence not have a need to address
internationalization issues. (A particular counterexample is the language N-Triples defined in the
RDF Test Cases WD). There may be an implicit (and false) assumption that all W3C recommendations
specify (only) web languages with processing models.



*** UNCHANGED ***
> For the section 3.5 we note that the language is somewhat offputting for us
> as specification developers given that our specification explicitly does
> not have a processing model. We have no particular suggestions about this,
> nor would we object if the I18N WG chose not to address this issue.
>


*** STRENGTHENED ***
The main concern of the RDF Core WG is section 8.
Any normative section of charmod MUST NOT depend
on the IETF IRI draft which is not finished and is not yet stable.


We draw attention to "SHOULD use Internationalized Resource Identifiers (IRI) [I-D IRI]".
The IRI draft is only a draft, the reference to it is not normative, and the strength of this SHOULD
dependency appears excessive ("not optional").
In particular, the IRI draft does not adequately address IRI equality (not merely functional
equivalence in retrieval). Moreover, the bidi section presents a learning curve which developers are
unlikely to want to climb before IRI has consensus around it; We have found the text in Xlink
section 5.4 and XML Erratum 26 adequately clear for some of the IRI questions, particularly those
that are most pressing for RDF and believe that charmod should merely:
- reiterate such text;
- reiterate the early uniform normalization model for the iris when
  regarded as unicode strings

*** DROPPED comment about being superceded ***

Jeremy

Received on Thursday, 23 May 2002 05:55:08 UTC