Re: Social API: Scope

Well, to be fair, if there are existing XML formats used in implementations
today that can be used as part of the comparison and can help seed the
discussion, then by all means let the group know.
On Aug 3, 2014 11:47 AM, "Harry Halpin" <hhalpin@w3.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 08/03/2014 07:57 PM, henry.story@bblfish.net wrote:
> >
> > On 3 Aug 2014, at 19:14, Erik Wilde <dret@berkeley.edu> wrote:
> >
> >> the assumption here being that tomorrow, RDF might be cool. maybe
> >> it will be, and we'll see tomorrow, i guess. to quote tim bray,
> >> what matters is the bits on the wire. it's kind of hard to get
> >> around this simple truth. cheets, dret.
> >
> > Teenagers make their decisions based on coolness. As you get older
> > you try to make them based on experience, and where possible try to
> > use foundations that are secure. In this case maths, logic and web
> > architecture.
>
> Note that the charter quite clearly says we are to focus on JSON as
> *syntax* - i.e. "A JSON-based syntax".  If somehow people have
> real-world software and actual deployments that require XML or some
> other non-JSON compatible RDF, go for it but this is very much
> secondary and should not tackled until we get the JSON serialization
> agreed upon, at least in this Working Group. If you want to start
> working on that now, a Community Group can be made at any time.
>
> Furthermore, the WG should also use URIs - "should include at least
> the ability to describe the data using URIs in an extensible manner".
>
>  The charter is clear: JSON and URIs. This isn't up for debate.
>
> Now rather than rat-holing, please provide competing JSON-based syntax
> alternatives to ActivityStreams. That *would* be useful.
>
>
>
>
>
>
> >
> > The idea is simple: You specify the meaning of the words, then you
> > allow the data to be expressed in whatever syntax is more
> > convenient.  Because it is useful to have a default, you take the
> > fashion of the moment - currently JSON-LD - as the serialisation on
> > the wire to agree on.
> >
> > For those with legacy software one can the write a JSON to JSON-LD
> > mapper to make integration easier.
> >
> > Then if between the time you start this process and the time it
> > ends you find another serialisation more fashionable ( say as
> > happend with Atom between Tim Bray - father of XML - pushing it,
> > and a few years later when JSON started becoming cool ), then you
> > don't have to change all the existing software.
> >
> > That also makes a lot of economic sense, which it is true is what
> > managers tend to think as being cool. So I can't completely escape
> > being cool. (sigh!)
> >
> >
> >>
> >>> On Aug 3, 2014, at 10:01, "henry.story@bblfish.net"
> >>> <henry.story@bblfish.net> wrote:
> >>>
> >>>
> >>>> On 3 Aug 2014, at 18:53, Harry Halpin <hhalpin@w3.org>
> >>>> wrote:
> >>>>
> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>>>
> >>>>
> >>>>
> >>>>> On 08/03/2014 06:02 PM, Erik Wilde wrote: hello james.
> >>>>>
> >>>>>> On 2014-07-31, 10:32 , James M Snell wrote: FWIW, AS2
> >>>>>> does not *re-base* itself on JSON-LD, it aligns with
> >>>>>> JSON-LD. It's a critical difference.
> >>>>>
> >>>>> i think this will get interesting when it comes to defining
> >>>>> an extension model. what was great about AS1 was that it
> >>>>> had both an XML and a JSON syntax, so it was useful for
> >>>>> both communities. once you subscribe to some layer higher
> >>>>> than that, it gets a bit trickier to have a well-defined
> >>>>> domain-based extension model, without resulting in rather
> >>>>> horrible structures in one of the underlying syntaxes.
> >>>>>
> >>>>> i tried to work on an AS2 XML encoding for a little while
> >>>>> (analogous to http://activitystrea.ms/specs/atom/1.0/),
> >>>>> because it might be helpful to also serve the XML/Atom
> >>>>> community. but it gets rather tricky to translate AS2's
> >>>>> "alignment" with JSON-LD into reasonable XML constructs.
> >>>>> that's because as an XML user, you'd like to see
> >>>>> XML's/Atom's extension model to be used rather than some
> >>>>> more complicated way of folding what's required by JSON-LD
> >>>>> into some generic XML mapping.
> >>>>>
> >>>>> i think it wold be important to discuss whether an XML
> >>>>> syntax is a requirement. if it is, my guess is that this
> >>>>> will have some implications for how much layered models
> >>>>> such as JSON-LD can be used, and where the line has to be
> >>>>> drawn to avoid dependencies on their implicit models.
> >>>>
> >>>> Actually, according to the charter only a JSON-based syntax
> >>>> is a requirement. The WG can of course have an XML syntax,
> >>>> but the focus on should be on JSON.
> >>>>
> >>>> cheers, harry
> >>>
> >>> If the group would manage to agree at the semantic level ( ie,
> >>> one an RDF vocabulary for whatever ) with a default syntax (
> >>> say JSON ), then these issues would just go away.
> >>>
> >>> Otherwise you'll just spend two years debating syntax issues.
> >>> Yesterday XML was cool. Right now JSON is. Sometime in the
> >>> future something else will be....
> >>>
> >>> Henry
> >>>
> >>>
> >>>
> >
> > Social Web Architect http://bblfish.net/
> >
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJT3oOzAAoJEPgwUoSfMzqczFkP/3o0baI+695BuE53nA/EICBH
> wf/ivA8vDfk+6trB1CMTpQlVJybG8W8oI6lNU5yplcBoDak2mwP7YWcIWyNvxGJ2
> ilwD/xJPOzqt/rBbulpp9wgIcmruzG0TMLuSy/tq0wI9iDDV7qOQ6ge6X1NHw13r
> pxtqPJSBxLyJpNqyBSgxXiTLdxVCwrQvqScWy/u4ZnC/SYO/T+fUn9VMxif+8Wwd
> G1cZ36gSHAPEQ7vNWheEMVg6Dv8lXs445rfyPkt09KNEK251YdsQC3NDInOZvngK
> VdLjEIS3Lk1uMKR7JfzaIr7ESmsqsN/gl2M4Zxupg8L831tyhQvtYxrHrQ9spq55
> XZ852colase8TRy+wJk0G6erKm1ysj1IH8Fm2uMlThydZq2mIxtIRlrhZlRkXKmm
> vqifuZXmmaPKxh2JlMHVIjNsudznPzy26vwc9jivlkZOIGTAHaKhSIOA+kdXvGVO
> H0jkipp7Pft8QM7BbVDktiOT+gdAirleuBZB8epIEVBtaYTVRk0T8pebUdo+t4fJ
> owEyaztfpl3jwohzg3zSw0Rqf89rjBpfgtpAUt2g3u2PZ0VGrw0amEgnXTZMMze+
> J/R+yZcg4p0X8XE7EvttEq4FMH8Ljo8whi6pd0E5pdJ7rg+RHlzsJ9jR1bIUEvDu
> PJpaESjcq2gLunrslwpc
> =NAga
> -----END PGP SIGNATURE-----
>
>