Re: extension model of RSS/Atom (ISSUE-16 discussion)

hello james.

On 2015-04-07 11:46, James M Snell wrote:
> The RELAX-NG model in RFC 4287 is *non-normative*
> RFC 4287, Section 1.3: "Some sections of this specification are
> illustrated with fragments of a non-normative RELAX NG Compact schema
> [RELAX-NG].  However, the text of this specification provides the
> definition of conformance.  A complete schema appears in Appendix B."
> RFC 4287, Appendix B: "This appendix is informative."

like i said, it could have been XSD or whatever. the idea behind that 
was was to not require a specific schema language, but to use it as a 
documentation device. which is a pretty good approach, i think.

there's a long history in many IETF groups of not being too fond of 
schema languages, and there are good reasons for that. but that's a 
different issue. the important aspect is that the extension model is 
well-defined (the prose being the normative definition).

> The Atom spec does go on to describe "simple" vs. "structured" extensions
> What this is saying is that extensions can be used throughout the Atom
> document but must be ignored when not supported. There is some
> distinction given between simple and structured extensions but those
> are largely a parsing concern, not a processing concern. The only
> *processing* requirement for extensions is the must-ignore rule.

but it's not a blanket "anything can appear anywhere and just ignore 
everything" rule. the normative prose (assisted by the non-normative 
schema) tells you *where* extensions should be expected, and thus also 
defines the ways in which somebody actually producing extensions should 
constrain themselves when doing it.

> While consuming implementations are not required to use the standard
> JSON-LD Processing Algorithms [JSON-LD-API], it is important to note
> that the algorithms, as currently defined, will silently ignore any
> property that is not defined in a JSON-LD @context. Implementations
> that publish Activity Streams 2.0 documents that contain extension
> properties should provide a @context definition of those extensions."
> I would argue that the processing semantics here are identical to
> those used in Atom. If there's an extension you do not understand,
> ignore it. JSON and JSON-LD handle the structural concerns so there's
> no need for AS2 to delve into the "simple" vs. "structured" question.
> AS2 provides a non-normative RDF model that is informative if someone
> wants to do something at a higher level.

as suggested in today's call, i think it would be good to walk through 
the steps of defining extensions (beyond the base schema), one time 
doing it in a way based on JSON-LD/RDF, and the other time doing it in 
plain prose/JSON.

Atom is doing things differently because XML provides a better way of 
separating vocabularies with namespaces. that's an important benefit 
that neither JSON nor JSON-LD have. that also makes it easier to 
separate possible future spec changes from openness/extensions. again 
that's something that we don't get out of the box.

we might get closer to understanding the finer points of the differences 
once we work on the test cases. i think it was you (but i may be wrong) 
suggesting that the test cases should include requirements for what 
should be reported to applications. i think once we have test cases 
using extensions, we'll get closer to discussing the issues of which 
extensions should be considered conformant, and in which way they should 
be reported to applications.

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Tuesday, 7 April 2015 20:06:54 UTC