constraining XRD (YADIS 0.9 section 7)

[Larry Drebes]

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 
interested in.
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.
>
>
>