RE: [xri] Draft of schema

["Barnhill, William [USA]" <barnhill_william@bah.com>]

Scott Cantor wrote on 2009-08-25:
>
> As an implementer, I find it easier to know where the extensions live than
> constantly process "anything goes". That might be because I don't use SAX.
>



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.  From reading the various recent comments on this list would the following address everyone's concerns?

XRD = element XRD {
        attribute xml:id { xs:ID } ?,
        other.attribute *,
        Signature ?,
        Expires,
        Subject,
        non.xrd.elemnt *,
}

Subject = element Subject {
        attribute isHost { xs:boolean },
        other.attribute *,
        URI,
        ( Alias | Type | Link ) *
}

This means:
- Order of the elements under the root is non-ambiguous
- Signature if present is at the top
- Subject is not optional. Is there a use case for an optional Subject?
- Subject now has a single URI child that contains the subject URI.  This is a bit of a hack but I can't see creating two URI types (URI and SubjectURI?) when we can re-use the one and specify in the spec that the behavior of a priority attribute on a subject URI is undefined.
- Elements from extension namespaces are always after all core processing has been done if you are using a streaming parser.  XPath-based extraction is also easier in my opinion.
- An empty Expires statement explicitly states that it does not expire (not discussed on the list AFAIK, but something I'd suggest)
- Match attribute on Subject is removed
- Attribute isHost provides an un-ambiguous and easily parsed method for determining if the subject URI addresses a host or not

What do you think?

=Bill.Barnhill