Re: [security-services-comment] comments re sstc-saml-metadata-ui-v1.0-csprd01

["Cantor, Scott" <cantor.2@osu.edu>]

On 10/17/11 6:57 PM, "Tom Scavo" <trscavo@gmail.com> wrote:

>The following are some preliminary comments regarding
>sstc-saml-metadata-ui-v1.0-csprd01 (26 July 2011).
>
>***The document does not contain any line numbers so I'm not sure what
>you want me to do. Can you please provide an official version of the
>document with line numbers? Please advise.

We have nothing to do with prepping documents anymore, that's up to TC
admin. It isn't going to get fixed quickly if at all, so my advice is to
refer to section numbers, or perhaps use the Open Office source directly.

>In the meantime, here are a few comments regarding the XSD document:
>
>- Since type mdui:UIInfoType is defined with minOccurs="0", an empty
><mdui:UIInfo/> element is allowed. Is this intentional? Seems like
>such an element should be avoided.

XSD can't handle what we would have to specify since none of the
individual children should be required, and precluding it in prose doesn't
matter much. The wrapper element doesn't have any semantics on its own.
This would be a "if we had some other reason to cycle the document"
change, but not worth doing otherwise.

>- Same comment for type mdui:DiscoHintsType.

Same reasoning.

>- Since the height and width XML attributes defined by type
>mdui:LogoType are required, a link to a non-bitmapped image is
>effectively precluded. Is this intentional? The fact that
>non-bitmapped images (such as SVG images) are not supported very well
>in current browsers is not sufficient reason to preclude such images
>IMO. Future browsers and non-browser clients might very well leverage
>non-bitmapped images.

I don't see why specifying a size precludes SVG. Just because vector
images in theory scale doesn't mean they really do. There are still
expected sizes, and we know that even with bitmaps, people are scaling
them. The point of the properties is to provide differentiation between
icons of different general size categories.

The type of graphic could also be leveraged, I imagine, based on the file
extension (or be probing the URL).

>Once you provide a document with line numbers, I will be happy to
>submit additional comments.

I'll put a comment into the Jira issue for this review if I can, but I
suspect the documents are frozen as far as OASIS is concerned. Line
numbers are a convenience, but they're hardly a precondition to comment.

Thanks,
-- Scott