<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
If you have ideas on the proper W3C friendly way to name the subject of the meta-data for all the protocols relating to a DNS name, I am quite interested in your opinion.<br>
</blockquote>
<br></div>
There is a large amount of data out there regarding different ways of naming things, both with URIs and without. I don't think that my opinion is any more helpful than anyone else's on this subject, but I would say this about XRD, and how it appears to disallow certain extensions in this area that might be helpful:<br>
<br>
i) The Subject element seems to be of xsd:type anyURI, which disallows someone from creating their own "registry" of (string) names, for example, and/or defining subjects as simple string values (as proposed below by Dirk I think). It would be possible within the rules of XSD/RelaxNG to define a more open content model - start with a string, and then define a restriction to anyURI for that kind of XRD usage, but allow extensions by others to either restrict the open type more, or use it as-is.<br>
</blockquote><div><br>John, thanks, that's very insightful. I think the scope of XRD is intended to be as a descriptor for any resource with a URI, which is why the XRI TC choose the anyURI type. But if there's a strong case for making it even wider, that could be considered. That's what the public review period can help determine (which should begin ~ Nov 1 - we're just finishing the Committee Draft vote right now).<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
ii) There seems no extension currently possible on the Subject element that would allow the creator of the XRD to indicate the "type" of the Subject and thus make the relationship known that way.<br></blockquote>
<div><br>That does not require an extension to the Subject element -- it's handled by its sibling element called <Type>. An XRD may have 0 or more <Type> elements (which take URIs as values) to define the type. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
FWIW, SAML 2.0 does a nice job of allowing extensions such as the above.<br>
<br>
I find it odd that an XRD could really have no Subject, but again, I don't know the use-case for that, or whether this is simply done to allow someone to create Subjects which aren't named with URIs (in which case, I would suggest allowing XSD extensions might be a better path).</blockquote>
<div><br>I believe the use case for Subject being an optional element was that in some cases the Subject will be implicit and therefore not needed.<br><br>Best,<br><br>=Drummond <br> <br><br></div></div>