[oslc-core] Requests for unknown or unsupported properties

[Samuel Padgett]

Thanks everyone for weighing in.

John writes:

> It's a "subtle enough" consequence of existing normative text that I
> would generally support proposals for additions of clarifying
> *informative* text.  I would have a harder time seeing the utility
> of adding normative text for this specific case (at [2] or [3]), but
> perhaps it has a place at [1].
>
> My reasoning:
> [2] and [3] both describe the semantics of the syntax in terms of
> what is to be included ("included" and "part of a member list
> pattern... to match", respectively), not in terms of what must be
> present.  Including 0 things yields 0 things.  The "match" word used
> in [3] makes this a bit clearer, admittedly.

I guess I still don't see where it's really said in either [2] or [3]. Even
if it's implied, I'd argue it should be called out explicitly to avoid
confusion. I know at least one implementation returns errors in these
cases.


> [1] (Core) allows servers to discard unknown property values.  One
> might quibble that it does not define "unknown" in this context with
> "hit reader over the head" obviousness, but it comes pretty darned
> close by saying "An OSLC Service MAY discard property values that
> are not part of the resource definition or Resource Shape known by
> the server. " in the very next sentence.

I read [1] to refer to creating or updating resources. If it applies to GET
requests as well, I propose we add clarifying text.


> [1] http://open-services.net/bin/view/Main/OslcCoreSpecification?
> sortcol=table;table=up;up=#Unknown_properties_and_content
> > [2]
> > http://open-services.net/bin/view/Main/OslcCoreSpecification?
> sortcol=table;table=up;up=#Selective_Property_Values
> > [3] http://open-services.net/bin/view/Main/OSLCCoreSpecQuery


--
Best Regards,
Samuel Padgett | IBM Rational | spadgett at us.ibm.com