constraining XRD (YADIS 0.9 section 7)
ltd at janrain.com
Wed Feb 8 02:03:25 UTC 2006
In section 7.3 it would be helpful to differentiate between "YADIS
constraints on the schemas", and where we are re-stating the schemas as
they stand. Two constraints worth removing:
7.3.3, "MUST contain one or more Service elements."
This is not a necessary constraint. True, a document with no Service
elements is of limited use to an application, but it needn't be an
invalid case. An example may be someone with a hosted YADIS service with
no services yet configured. An application will probably treat this much
the same as a document that contained Services only of types it was not
Instead of focusing on the minimum requirement here, it might be more
productive to say what may be included. e.g. "may contain as many
Service elements as necessary to describe the YADIS services."
7.3.4 "MUST contain at least one Type element"
There is a need for people to know "How to define a new YADIS Service."
In answering that, we can state that YADIS Service designers should
define a Type value and require its presence in the Service element for
use with their protocol.
"Type" is, however, not a required element in the XRD schema. I do not
believe a YADIS parser should treat a Service element with no Type as an
error, as they might do after reading the MUST here.
Joaquin Miller wrote:
> Thanks, Kevin.
> Sounds convincing. Which constraints shall we consider removing?
> Cordially, Joaquin
>> Section 7.3 of YADIS 0.9 speaks of "constraints on the XRDS and XRD
>> schemas." Is it necessary to place such additional constraints on
>> the document in order to meet the goals of YADIS?
>> I think the fewer constraints we need to make the simpler the
>> specification can be. And the fewer constraints there are, the fewer
>> roadblocks we create in being compatible with other tools that use
>> the XRD format.
More information about the yadis