Re[3]: IRI versus URI terminology

Lofton,

Wednesday, June 7, 2006, 1:08:31 PM, Lofton Henderson wrote:

> 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 was not suggesting that we change the attribute name from 'uri' to
'iri'. That's just as bad in my opinion. We need an attribute name
that doesn't tie us to the type, ex: xlink:href.

>>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.
We are about to request Last Call publication, not CR or PR. The
specification will change, I think we can count on that. We will
invalidate cascade profiles, existing content and existing tests. Of
course, the smaller the changes the better.

From my perspective; doing a search/replace in implementations and in
test files is quite easy compared to other changes we may be forced to
do.

> But if you wish to raise the issue -- end of telecon is the
> drop-dead for raising and resolving.
No. I was actually thinking of sending this as a Last Call comment. We
can publish as is, I don't care.

An attribute name change on a single element, is quite reasonable in my
opinion (when going from LC to CR).

> The spec text becomes frozen when we pass the resolution, unless the
> resolution includes "...with these changes <list-em>".
I think you misunderstood me, I wasn't proposing that we agree on a
new name before the end of telecon tomorrow. It doesn't have to be
changed now; we can change it later (between LC and CR).

-- 
Regards,
 Benoit   mailto:benoit@itedo.com

 
> -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:42:47 UTC