Given that Gabe was the initial champion
of the version attribute for XRD, if he’s satisfied, I’m satisfied.
I think Eran’s argument about using the XML namespace for the new XRD
schema as the version identifier is a strong one.
So on this first issue, I propose we go
for the close:
The
new spec will be called “XRD 1.0” unless anyone explicitly objects
by responding to this thread.
Given that it’s Thanksgiving week in
the U.S., I suppose we ought to consider this provisional until next Monday.
**************
On the second issue of the XML namespace
identifier, I personally am fine with using either a numeric or a date
identifier, (although I can’t resist pointing out that the reason we used
an XRI the first time around was to provide an identifier for which versioning
semantics are actually _defined in a
machine-understandable format_, which I would favor over any
non-machine-understandable option). That said, I’m happy to leave it to
the editorial team to make a recommendation.
**************
A third issue we’ve run into before
is one I’d like to nip in the bud. “XRD 1.0” is very short
and concise and also the way the spec will typically be referred to. However
sometimes OASIS requires TCs to spell acronyms out. For example, the formal
name of the SAML 2.0 Core spec (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)
is:
Assertions
and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0
Because “XRD” is not the name
of the TC, I believe that we as TC can declare that the acronym IS the name of
the specification. In that case, since OASIS does require the use of a capital “V”
before the spec version number, the formal name of this specification would be:
XRD
V1.0
…and not…
Extensible
Resource Descriptor (XRD) V1.0
Anyone who does NOT want to use the
shorter option – “XRD V1.0” – as the formal name of the
spec, please reply back to this thread, or else we’ll assume that’s
our title (unless Mary McRae has any other issues once she’s back from
vacation).
=Drummond
From: Gabe Wachob
[mailto:gwachob@gmail.com] On Behalf Of Gabe
Wachob
Sent: Monday, November 24, 2008
10:17 AM
To: Eran Hammer-Lahav
Cc: Drummond Reed; Nat Sakimura;
mary.mcrae@oasis-open.org; OASIS XRI TC; sakimura@spmd.nri.co.jp
Subject: Re: [xri] RE: Version
identifier for XRD spec
I'd be happy with calling it XRD 1.0 if we use a dated namespace so
people don't have *any* confusion about the fact that this is the "most
current" spec relative to XRI...
Its also a sort of emerging best practice for namespaces from the W3C,
afaict.
And of course, I'm happy with an HTTP namespace ;)
I'm happy with dropping version - that was there mostly to allow
backwards compatibility - the idea being that a future interpreter could pick
up an older XML document and understand what it was looking at. This would
leave us as spec writers free to add new elements in a "backwards
compatible" manner, while allowing the documen to give hints to "up
to date" implementations what level the spec was at. The idea was that you
would be able to rev the schema much slower than the spec interpreting
it.
On Nov 24, 2008, at 9:11 AM, Eran Hammer-Lahav wrote:
My vote is to:
- Name the spec XRD 1.0
- Drop the ‘version’ attribute
- Drop the proposal to have multiple
‘profiles’ (i.e. XRDS-Simple)
- Use an HTTP namespace under the OASIS domain
with version 1.0. If people find this confusing, I would be ok with a
dated namespace. As a last resort, I would support using a version 3.0
namespace with an explanation why the spec itself is version 1.0.
Here is why:
I think the real question here is what to do with the ‘version’
attribute. In many ways, it is very similar to the ‘profile’
attribute proposed earlier to support the XRDS-Simple use case. I am –1
on both and here is why. My understanding of the ‘version’
attribute is that it refers only to the resolver workflow, not to the schema
which is independently versioned via an XML namespace.
I cannot think of use cases where the schema does not change at all, but the
meaning of the document does. The most likely scenario to happen is adding
elements via XML namespace import, and in that case, the resolver will need to
take those new additions into account (as they may change the meaning of the
document). I believe that the schema itself is more than just a format but also
tightly linked to its meaning. If we want to change the meaning but not the
schema, we should still change the XML namespace. Either way, existing parsers
will need to change so why does it matter what breaks them (different version of
different namespace).
In addition, I have changed my views on the ‘profile’ attribute. I
think at this point the only element which might be considered
‘advance’ is <Ref> and it is an important requirement for any
delegation of metadata. The only other issue raised by developers was the
‘priority’ attribute but again, it is too important to remove.
If we remove these two attributes, we are left with a single unified schema
which will get a new namespace. Since this new namespace will be an HTTP URI, I
do not think it matters if it is version 1.0 or dated. It will be sufficiently
different form the XRI namespace (which more people didn’t understand)
and from the version attribute value. Because of that I lean more towards a
version 1.0 in the namespace than a date, but will take a date over version
3.0.
The spec itself should be XRD 1.0 either way, not matter what namespace we end
up using (and assuming we are dropping the ‘version’ attribute). It
is better to version it 1.0 and put a comment why the namespace has 3.0 in it,
than make everything 3.0...
EHL
On 11/23/08 11:18 PM, "Drummond Reed" <drummond.reed@cordance.net> wrote:
Nat, RE your [Q1], I don't think
OASIS mandates how schemas are versioned.
That's up to individual TCs (I'm trusting Mary or Robin will correct me if
I'm wrong.]
RE your [Q2], I think that it is also up to us when we make a version
change. Changing the schema would seem to be one of the conditions under
which we would definitely make a version change, but it does seem like other
spec changes could also trigger a version change (for example, as you
mentioned, verification rules).
Suggestion: since much of this seems to hinge around whether the XRD schema
retains a version attribute, why don't selector see if we can decide that
first.
1) Who has strong feelings one way or another about whether the XRD schema
should have a version attribute?
2) If so, should the use of the version attribute be required?
3) If there is a version attribute, who has strong feeling about it being
numeric (as it currently is in XRI Resolution 2.0)? Or a date value?
=Drummond
> -----Original Message-----
> From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]
> Sent: Sunday, November 23, 2008 6:11 AM
> To: mary.mcrae@oasis-open.org;
OASIS XRI TC
> Cc: Gabe Wachob; Drummond Reed; Eran Hammer-Lahav; sakimura@spmd.nri.co.jp
> Subject: Re: [xri] RE: Version identifier for XRD spec
>
> So, to sum it up, there has been several information points/resonings
> available around versions:
>
> (1) Since it is a new spec, it shoud start from 1.0. Otherwise people
> start looking for 1.0.
> (2) Since there is <XRD version="2.0"
xmlns="xri://$xrd*($v*2.0)"> in
> XRDS right now.
> using 1.0 may confuse people. Perhaps
we should use 3.0.
> (3) However, if version attribute goes away, this is of less concern.
> Version of the schema can be represented
in xmlns, and it will be
> a new
> http based version string possibly
starting from 1.0 or dates in
> W3C style.
> Besides, schema version and spec
version can be separate.
> (4) OASIS rule mandates the specs to be versioned numerically.
>
> I have a couple of questions at this point.
>
> [Q1] Is the OASIS versioning rule on the spec also applicable to the
> schema contained in the spec?
> [Q2] Is there a case where we want to preserve "version"
attribute
> separate from the schema version?
> e.g., when verification rule is changed etc., should it
always
> require the schema version change as well?
>
> If the answer to [Q1] is no, then we can use date based name space in
> <XRD ... > and cause
> less confusion even if we adopt XRD 1.0. If the answer is "Yes",
then I
> would be more inclined to "3.0".
>
> For [Q2], I am yet to come up with a case. If any of you could think of
> it, please let me know.
>
> =nat
>
>
>
>
> Gabe Wachob wrote:
> > Lets call it XRD 7!
> >
> > -Gabe
> >
> > On Fri, Nov 21, 2008 at 11:11 PM, Drummond Reed
> > <drummond.reed@cordance.net
<mailto:drummond.reed@cordance.net>>
wrote:
> >
> > Mary McRae, our TC admin, clarified that
OASIS specs must use a
> > numeric
> > version identifier (see thread below).
> >
> > So, mates, now we really do have to decide
between "XRD 1.0" and
> > "XRD 3.0".
> >
> > A suggestion: if, as we discussed on
Thursday's call, the new XRD
> > spec will
> > no longer have a "ver" attribute on
the XRD element, then the
> > issue of the
> > previous version attribute value being
"2.0" (as specified in XRI
> > Resolution
> > 2.0) will go away. In that case I think it
makes sense to call the
> > spec "XRD
> > 1.0" because as Eran pointed out,
there's never been a spec from
> > the TC
> > called "XRD" before.
> >
> > OTOH, if the decision is that the ver
attribute on XRD element
> > should stay,
> > then I think it makes sense to call the spec
"XRD 3.0" because it
> > really is
> > the next version of XRD. We can always put a
note in the
> > frontmatter telling
> > readers not to look for an "XRD
2.0" or "XRD 1.0" spec, but
> > instead to look
> > at "XRI Resolution 2.0" and
"XRI 1.0" for the predecessor
> > specifications.
> >
> > All things being equal (which they never are
;-), I favor planning
> for
> > future growth and extensibility, which means
I favor keeping the
> > versioning
> > attribute, which tips me ever so slightly
towards "XRD 3.0". (Which
> is
> > ironic because I prefer the spec name
"XRD 1.0" because it's a new
> > spec.)
> >
> > I don't think the issue is worth taking a
bunch of list bandwidth
> > to figure
> > out, so I'd recommend that:
> >
> > a) Anyone else on the list with strong
feelings either way, please
> > post your
> > thoughts by Monday.
> >
> > b) Eran and Nat as the editors discuss it and
make a recommendation.
> >
> > =Drummond
> >
> >
> > > -----Original Message-----
> > > From: Mary McRae [mailto:marypmcrae@gmail.com
> > <mailto:marypmcrae@gmail.com>]
On Behalf Of Mary McRae
> > > Sent: Friday, November 21, 2008 5:23 AM
> > > To: 'Drummond Reed'
> > > Subject: RE: Version identifier for XRD
spec
> > >
> > > You found the right (and required) answer
;-)
> > >
> > > Mary
> > >
> > > > -----Original Message-----
> > > > From: Drummond Reed [mailto:drummond.reed@cordance.net
> > <mailto:drummond.reed@cordance.net>]
> > > > Sent: Friday, November 21, 2008
1:22 AM
> > > > To: 'OASIS XRI TC'; mary.mcrae@oasis-open.org
> > <mailto:mary.mcrae@oasis-open.org>
> > > > Subject: Version identifier for XRD
spec
> > > >
> > > > Mary,
> > > >
> > > > From today's XRI TC call I had an
action item to send you and
> > the TC
> > > > list an
> > > > email asking about OASIS spec
naming guidelines. Based on the
> > helpful
> > > > info
> > > > about spec packaging you gave us
two weeks ago, the TC is
> > currently
> > > > planning
> > > > two new specs, both of which we
intend to take to OASIS
> > Standard level:
> > > > XRI
> > > > 3.0 and XRD xxx (xxx = version
identifier TBD).
> > > >
> > > > XRI 3.0 will consist of four parts
(1: Syntax, 2: Resolution,
> > 3: http:
> > > > and
> > > > https: Bindings, and 4: info:
Binding). XRD will probably be a
> > single
> > > > spec,
> > > > though it might be two parts.
> > > >
> > > > Now, the question is about
versioning on the XRD spec. This is
> > a new
> > > > spec
> > > > that represents splitting off a
significant portion of the
> > content of
> > > > the
> > > > XRI Resolution 2.0 spec into a new
spec that defines a generic
> > metadata
> > > > discovery format and protocol which
the new XRI 3.0 Part 2:
> > Resolution
> > > > spec
> > > > will then profile (as will other
specs, e.g. SAML, OpenID,
> > OAuth, etc.
> > > > who
> > > > want to use interoperable
discovery).
> > > >
> > > > Our first question is: does an
OASIS spec need to use a
> > numeric version
> > > > identifier? In researching this
tonight, I believe the answer
> > is at:
> > > >
> > > >
> > > > http://docs.oasis-
> > > > open.org/specGuidelines/namingGuidelines/metadata.html#ver
> > <http://open.org/specGuidelines/namingGuidelines/metadata.html#ver>
> > > > sion
> > > >
> > > > ...which states:
> > > >
> > > > *******************
> > > > A specification Version is
represented textually by a numeric
> > string
> > > > composed of digits [0-9] and period
(".") corresponding to any
> > of the
> > > > following lexical models provided
below (as examples), as may be
> > > > relevant to
> > > > the TC's work activity and
preference for major/minor version
> > notation.
> > > > Formally, using parenthesis to
indicate optionality and "#" to
> > > > represent a
> > > > digit, the allowable pattern is:
#(#).#(#)(.#(#)). Use of any
> > other
> > > > pattern
> > > > for version number must be
negotiated with the TC
> Administration.
> > > >
> > > > Examples:
> > > >
> > > > 1.0
#.#
> > > > 1.01 #.##
> > > > 1.2.1 #.#.#
> > > > 10.1 ##.#
> > > > ********************
> > > >
> > > > If so, that answers the question,
and we just need to decide
> what
> > > > version
> > > > number to give it (in short: one
rationale is to call it 1.0
> > because it
> > > > is a
> > > > new spec; another is to call it 3.0
because it derives from two
> > > > generations
> > > > of XRDS before it -- but that's our
issue to figure out).
> > > >
> > > > However, if we do have any
flexibility, we want to at least
> > ask you
> > > > about
> > > > using a year/date identifier
instead of a version number.
> > > >
> > > > Thanks in advance. (BTW, I'm
thinking of setting up a call in
> > early
> > > > December
> > > > between you and the editors of
these new specs to a general
> > Q&A about
> > > > all
> > > > things involved with the mechanics
of an OASIS spec. Sound
> > like a good
> > > > idea?)
> > > >
> > > > =Drummond
> >
> >
> >
> >
--------------------------------------------------------------------
> -
> > To unsubscribe from this mail list, you must
leave the OASIS TC that
> > generates this mail. Follow this link
to all your TCs in OASIS at:
> > https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
> >
> > --
> > Gabe Wachob / gwachob@wachob.com
<mailto:gwachob@wachob.com> \
> > http://blog.wachob.com
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|