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


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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

Subject: RE: [xri] Draft of schema

Barnhill, William [USA] wrote on 2009-08-25:
> I also find it easier if I know where the extensions are but I prefer the
> way XMPP does it. They have their bits inside a single well defined
> within the root element, and extensions are siblings of that well defined
> element.

I guess that's sort of the reverse, but seems to make Extensions drive the
structure, since using an Extensions wrapper means it never appears unless
you need it.

> From reading the various recent comments on this list would the
> following address everyone's concerns?

I suspect the problem with your proposal is that they want all those
elements to be optional.
Note that Link has the same problem, with KeyInfo. But one fix there would
be to just wrap KeyInfo into this namespace, which I can't recall the end of
the discussion on.

> This means:
> - Subject is not optional. Is there a use case for an optional Subject?

Pretty sure that was being repeatedly argued.

> - An empty Expires statement explicitly states that it does not expire
> discussed on the list AFAIK, but something I'd suggest)

I'd avoid allowing empty elements, personally, but if you do mean empty,
what you need there is xsi:nil="true" on it, not just an empty element.

> What do you think?

Leaving the subject matching mess aside, I think it's tractable if people
can deal with your changes to cardinality, but I guess I should note that
just like Link can be fixed by wrapping KeyInfo, I suppose Signature could
also be wrapped at the XRD level. Not typical, but wouldn't hurt anything
either. I didn't think of it.

-- Scott

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