OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [bt-spec] Issue 78: revised solution


Dear Mark and Jim,

Issues 78, 100, 101, 102:

I think it would help greatly if you would consider proposing precise
alternative text in counterposition to, or amendment to, the proposed solution
for issue 78, or as proposed solutions to 100-102.

My current view, which Peter shares, is that the solutions to 100-102 should be
"no change".

I think that a debate over textual alternatives should enable the committee to
decide this issue at its next meeting, whereas a debate in principle, as at
present, can more easily meander without resolution.

Yours,

Alastair

Peter Furniss wrote:

> Doug,
>
> > What you've done improves things more than my simple change.  It makes me
> > wonder, though, why are we talking about URI values at all?  Wouldn't the
> > text be simpler throughout the specification if it discussed names rather
> > than identifiers and URN's rather than URI's?  I haven't resorted
> > to looking
> > up the proper RFC documents.  I might be ignoring something major
> > like http:
> > or uuid: not being valid URN schemes.
>
> If I'm reading rfc 2396 correctly (and contrary to my belief before I did),
> the URN and URL are defined by their use, not by their internal syntax.  So
> if I find in some xml,
>    xmlns:xsch="http://www.w3.org/2001/XMLSchema"
> the URI is a URN. But if I say "a human-consumable page about, and links to
> various representation for the XML schema is at
> http://www.w3.org/2001/XMLSchema" then it's a URL.
>
> So http was designed as a URL scheme, but that doesn't preclude the use of a
> value from it as a URN. As a scheme, I believe uuid: would be a URN scheme,
> but a value could be used as a URL if the context it was used in was known
> to have some lookup mechanism supporting it (that is definitely well into
> the angels-on-pinheads area). I think rfc 2396 implies that there is no real
> distinction between urn and url schemes, and they are all uri schemes.
>
> I'm no longer sure myself what the general understanding of URI, URL and URN
> is, and I'd welcome correction on the above - but it does seem to be a
> strict interpretation of the definition in rfc 2396 (I've included the
> paragraph in question at the bottom, though not the wider context).  The
> model text, since it is essentially explanatory, needs to build on what
> people understand, so URI or URN probably should build on that as well as
> the pedantic details.
>
> I think we probably want to stick with "identifier" as the parameter name,
> since transaction identifier is a common concept in this area, even if it is
> a name according to the definitions. I'm open on whether we describe it as a
> URN or URI.
>
> > If we go with the lesser change you've proposed, I have a couple of minor
> > corrections:
>
> Thanks - I've applied these to what is in the issues list as the current
> proposed solution.  In that text I've flagged the two sentences involved as
> being potentially affected by issues 100 and 101.
>
> Peter
>
> from http://www.ietf.org/rfc/rfc2396.txt
>
>  URI can be further classified as a locator, a name, or both.  The
>    term "Uniform Resource Locator" (URL) refers to the subset of URI
>    that identify resources via a representation of their primary access
>    mechanism (e.g., their network "location"), rather than identifying
>    the resource by name or by some other attribute(s) of that resource.
>    The term "Uniform Resource Name" (URN) refers to the subset of URI
>    that are required to remain globally unique and persistent even when
>    the resource ceases to exist or becomes unavailable.
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC