Next in thread → Next in month →

RE: [xri] Draft of schema

From
Scott Cantor <>
Date
2009-08-25T21:13:31+00:00
ID
00ca01ca25c8$dbe9f3f0$93bddbd0$@
Thread
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
element
> 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
(not
> 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
Next in thread → Next in month →