RE: [cgmo-webcgm] Recommendations on references [was: Chapter 3 review]

[Lofton Henderson <lofton@rockynet.com>]

At 07:41 AM 7/5/2005 +0200, Dieter  Weidenbrück wrote:
>How much would actually change if we support IRI?
>UTF-8 or 16 would become mandatory for linkURI, I guess,
>anything else?

Hard to say.  I haven't closely studied IRI  (RFC3987, [1]).  I just have 
the same generic impression as Dieter.  Maybe we should assign an action 
item to study and answer the question (even if we think that IRI isn't in 
the requirements of the principal consumers of WebCGM 2.0)?

Here is what the Abstract of RFC3987 says:

>    This document defines a new protocol element, the Internationalized
>    Resource Identifier (IRI), as a complement to the Uniform Resource
>    Identifier (URI).  An IRI is a sequence of characters from the
>    Universal Character Set (Unicode/ISO 10646).  A mapping from IRIs to
>    URIs is defined, which means that IRIs can be used instead of URIs,
>    where appropriate, to identify resources.
>
>    The approach of defining a new protocol element was chosen instead of
>    extending or changing the definition of URIs.  This was done in order
>    to allow a clear distinction and to avoid incompatibilities with
>    existing software.  Guidelines are provided for the use and
>    deployment of IRIs in various protocols, formats, and software
>    components that currently deal with URIs.

Regards,
-Lofton.

[1] http://www.ietf.org/rfc/rfc3987.txt



> > -----Original Message-----
> > From: Cruikshank, David W [mailto:david.w.cruikshank@boeing.com]
> > Sent: Tuesday, July 05, 2005 12:49 AM
> > To: Lofton Henderson
> > Cc: CGM Open WebCGM TC
> > Subject: RE: [cgmo-webcgm] Recommendations on references [was: Chapter 3
> > review]
> >
> >
> > Lofton,
> >
> > I'm still playing around with the action item to include
> > non-requirement for IRI support in the WebCGM 2.0 requirements
> > document.  It doesn't appear to go into any of the current
> > headings.  Maybe a new 2.1 Technical environment requirements?
> > And should it also try to cover the other updates to the other
> > references below too?
> >
> > The fact the web implementations of technical documentation are
> > mostly closed systems tells me that IRI is not needed and the
> > fact the user community (ATA and S1000D)doesn't specify a
> > requirement for multi-language support in addressing.  In fact
> > S1000D references RFC-2396, but only as a mechanism for enabling
> > URN syntax (RFC-2483). And, of course, ATA uses refloc, which
> > would be transformed into linkuri at deployment time and doesn't
> > allow anything beyond ISO-Latin1.
> >
> > Is it enough to say that the linking mechanism of the user
> > community have no requirement for internationization of the
> > character repertoire in links?
> >
> > thx...Dave
> >
> > -----Original Message-----
> > From: Lofton Henderson [mailto:lofton@rockynet.com]
> > Sent: Tuesday, June 07, 2005 4:11 PM
> > To: cgmo-webcgm@lists.oasis-open.org
> > Subject: [cgmo-webcgm] Recommendations on references [was: Chapter 3
> > review]
> >
> >
> > In processing Benoit's Ch.3 comments, there were a handful that
> > dealt with
> > normative and informative references.  Most are straightforward.
> > At least
> > one might be an issue...
> >
> > Should we change URI to IRI?
> >
> > I would like the ATA and S1000D folks to comment on that.  Is IRI an
> > immediate requirement, or not?  (Given that ATA Grex doesn't
> > allow unicode
> > for graphical or non-graphical text, I'd be surprised to hear
> > that IRI is a
> > requirement.)
> >
> > At 04:34 PM 4/21/2005 -0400, Benoit Bezaire wrote:
> >
> > >[...]
> > >
> > >3.1.1.1 Fragment definition
> > >   - Should we change URI references to IRI references? (see:
> > >   http://www.ietf.org/rfc/rfc3987.txt) (for the entire spec)
> >
> > Recommendation:  Stick with URI (rfc3986) for 2.0 unless/until
> > IRI is shown
> > to be important, immediate requirement for WebCGM 2.0 target
> > constituency.  (Try to postpone IRI till next version, 2.1.  Altho' we
> > might have to try to defend that if we have an OASIS-W3C collaboration..)
> >
> > >   - Should we update the XPointer reference (that specification has
> > >   been superceded)?
> >
> > Recommendation:  Change to Xpointer Framework (Rec 2003).  It's an
> > informative reference anyway.
> >
> > >[...]
> > >
> > >3.1.1.3 Fragment Character Repertoire
> > >   - Should we update our XML 1.0 (second edition) to the third edition
> > >   or go to XML 1.1 (Rec)
> >
> > Recommendation:  XML 1.0 3rd Edition.
> > Discussion:  "If not broken, don't fix it."  We have a simple normative
> > dependence on XML char. repertoire rules,  XML sec 2.2.  (Plus we
> > now have
> > XML content in the XCF.)  At the 2005 W3C Tech Plenary, I heard
> > controversy/argument about slow uptake of 1.1 for ??? reasons, and people
> > are sticking with 1.0.  So let's keep it simple.
> >
> > >   - Should we update our HTML 4.0 reference to 4.01 or XHTML?
> >
> > Recommendation:  HTML 4.01.
> > Discussion:  We have simple non-normative reference to "Target" names and
> > behaviors.  (Non-normative, because we actually copy what we need into
> > WebCGM text.)  We also have reference to how to use the <object>
> > element.  It's dicey whether that is normative or informative.
> > On the one
> > hand, we can't place normative requirements on HTML content,
> > which is where
> > the <object> element lives.  On the other hand, we *can* say that all
> > viewers must support the (recommended) set of <param> capabilities.  But
> > ... that doesn't seem to be a normative invocation of HTML / XHTML itself.
> >
> > Thoughts / objections about any of these?
> >
> > -Lofton.
> >
> >
> >
> >
> >
> >