W3C home > Mailing lists > Public > public-webcgm-wg@w3.org > June 2006

Re[2]: IRI versus URI terminology

From: Lofton Henderson <lofton@rockynet.com>
Date: Wed, 07 Jun 2006 11:08:31 -0600
Message-Id: <5.1.0.14.2.20060607110217.02359ec0@localhost>
To: Benoit Bezaire <benoit@itedo.com>,public-webcgm-wg@w3.org

At 11:49 AM 6/7/2006 -0400, Benoit Bezaire wrote:

>It seems to me that the 'uri' attribute should be renamed to href or
>xlink:href.

Which, like the change to 'iri', would invalidate existing cascaded 
profiles, existing content, and existing tests.


>I'll raise an issue about it once we have tracker.

My opinion: it is more important that we not invalidate cascaded profiles, 
existing content, and existing tests ... that is more important than 
getting the name just right.

But if you wish to raise the issue -- end of telecon is the drop-dead for 
raising and resolving.  The spec text becomes frozen when we pass the 
resolution, unless the resolution includes "...with these changes <list-em>".

-Lofton.


>Wednesday, June 7, 2006, 11:18:09 AM, Lofton Henderson wrote:
>
> >  At 06:42 PM 6/6/2006 -0600, Lofton Henderson wrote:
> >  Hearing no negative feedback, I went ahead and changed the
> > parameter names to 'namespaceIRI', 'fileIRI', and 'iri'.  See #3, #4, 
> #5 below.
>
> >  I want to backpedal slightly.  I was thinking that all changes
> > were only changes to terminology, or to the spec's names for
> > parameters, in such a way that no existing implementations or tests 
> would be affected.
>
> >  But that's not quite true, there is one exception  For #5, the
> > 'uri' would actually appear in XCF content, as in:
> >      <linkuri uri="http://example.org/" ...>.
>
> >  So changing 'uri' to 'iri' would affect existing implementations,
> > cascaded profiles, and tests.  Given that we have already decided to
> > leave 'linkuri' alone, throughout the document, for reasons of its
> > 8-year legacy, it actually makes sense to leave 'uri' as is.  (The
> > description still makes clear that the value of the parameter is the IRI.)
>
> >  So I propose that it should be 'uri' (in other words, undo this bit of 
> yesterday's changes).
>
> >  Comments?
>
> >  -Lofton.
>
> >
>
> >  At 12:08 PM 6/3/2006 -0600, Lofton Henderson wrote:
> >
> > I have made changes [1] -- more or less as proposed in the below
> > copied email.  Have a look especially at 3.1.1.1, revised to have
> > some strong similarities to current SVG Tiny 1.2 wording.
>
> >  [1] http://www.w3.org/Graphics/WebCGM/drafts/current-editor/
>
> >  Questions/comments:
>
> >  1.) 3.1.1.4 is the trickiest part, because IRI and URI both enter
> > into the equation.  Does it look okay?
>
> >  2.) I changed the text usage "namespace URI" to "namespace IRI".
> > Is that correct?  (I.e., "Namespaces in XML" does allow IRI?)
>
> >  3.) However in Ch.5, for this draft, I left the name of the new
> > DOM "namespaceURI" parameter alone wherever it occurred, until I
> > check with the WG.  I can think of no reason that changing the DOM
> > parameter name would have an impact.  RECOMMENDATION: change
> > 'namespaceURI' to 'namespaceIRI' in DOM chapter and ECMAScript chapter.
>
> >  4.) Same for the new DOM 'fileURI' parameter in Ch.5.
>
> >  5.) 4.3.8:  Similarly I left the name of the new XCF 'uri'
> > parameter alone in Ch.4.  Again, I guess there is no reason that
> > changing the parameter's name would cause a problem.  As long as we
> > change the DTD accordingly, then it should have no impact on
> > implementations that currently work, right?  (Actually, those
> > implementations would continue to work anyway -- there is no
> > semantic content in the parameter name!)  RECOMMENDATION:  change
> > 'uri' parameter to 'iri' in XCF chapter and external complete DTD.
>
> >  6.) However, I decided to leave the 8-year-old 'linkuri' ApsAttr
> > name as is, because of heavy legacy usage and familiarity.
>
> >  7.) Note the change to the description change of 'uri' in 4.3.8.
> > Was: "The href of this 'linkuri' attribute".  Now is: "The IRI of
> > this 'linkuri' attribute."  I don't think the description was very good 
> as it was.
>
> >  I'd like your feedback.  If any further changes, such as #3, 4, 5
> > above, then I'll do them next week for the LC text.
>
> >  -Lofton.
>
> >
> >  At 05:20 PM 5/31/2006 -0600, Lofton Henderson wrote:
>
> >
> > Hi Chris,
>
> >  I have the action item to fix the terminology, by changing "URI"
> > to "IRI" where appropriate -- unfinished Boeing item #24 [0].
>
> >  [0]
> > 
> http://www.w3.org/Graphics/WebCGM/drafts/20060528/proposed-changes-boeing/proposed-changes-boeing#Proposed-24
>
> >  I'm thinking that some material like [2] & [3] from Tiny 1.2 ought
> > to go into WebCGM section 3.1 [1], and/or into a new informative
> > discussion section of Chapter 2.  Your thoughts about that?
>
> >  I find "URI" 105 places in the WebCGM 2.0 (Submission) spec.  I'm
> > thinking the following general guidelines should get it right in most 
> places:
>
> >  a.) Most "URI" in the document should be changed to "IRI", except
> > most of those in 3.1.1.4 should remain "URI".  Any exceptions to this?
>
> >  b.) What about the commonly used phrase, "URI fragment" or "URI
> > fragment syntax"?  (Which refers to 3986 "fragment identifiers",
> > applied to the WebCGM fragment per the rules of 3.1).  Is it correct
> > to change these to "IRI fragment"?  I looked again at 3986 and 3987
> > and the answer isn't completely obvious to me.  However, Tiny 1.2 seems 
> to do it that way [2], [3].
>
> >  c.) namespace URI?  (Occurrences in ch.4 and ch.5).  I assume that 
> gets changed to "namespace IRI"?
>
> >  You advice is appreciated.
>
> >  Thanks,
> >  -Lofton.
>
> >  [1]
> > 
> http://www.w3.org/Graphics/WebCGM/drafts/20060528/proposed-changes-boeing/WebCGM20-IC#webcgm_3_1
> >  [2] http://www.w3.org/TR/SVGMobile12/linking.html#HeadOverview
> >  [3] http://www.w3.org/TR/SVGMobile12/linking.html#IRIandURI
Received on Wednesday, 7 June 2006 17:08:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:19:08 GMT