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

[Dieter Weidenbrück <dieter@itedo.com>]

How much would actually change if we support IRI?
UTF-8 or 16 would become mandatory for linkURI, I guess,
anything else?

> -----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.
>
>
>
>
>
>