Re: internationalization issues

It doesn't cause any problems *parsing*, but it means you can't use object
notation in most languages.

$foo->@context is not valid syntax in PHP or nearly any language I can
think of. It limits the use to array/hash notation, like $foo['@context']
in PHP.

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>


On Fri, Oct 23, 2015 at 10:03 AM, Amy G <amy@rhiaro.co.uk> wrote:

> The '@' symbol seems not to cause any problems with default json parsing
> in python and php, what were you using?
>
> Amy
> On Oct 23, 2015 9:14 AM, "Harry Halpin" <hhalpin@w3.org> wrote:
>
>> Elf,
>>
>> On 10/23/2015 04:49 AM, elf Pavlik wrote:
>> > On 10/22/2015 06:03 PM, James M Snell wrote:
>> >> On Thu, Oct 22, 2015 at 8:51 AM, Harry Halpin <hhalpin@w3.org> wrote:
>> >> [snip]
>> >>> I'll try to get to this next week, but my high-level feedback is
>> likely
>> >>> for AS2.0 to be successful everything outside the basic actor-verb
>> model
>> >>> and the kinds of metadata in Winer's RSS specs/Atom should be removed
>> >>> and put back in Activity Vocabulary.
>> > Harry, can you please reply with a short snippet of AS2.0 JSON data
>> > which uses at least one term defined in microformats.org vocabulary?
>> >
>> > I believe that you feel comfortable with backing you proposal with
>> > simple 5 lines of plain JSON which I see you keep promising to people!
>>
>>
>> People who send email use natural language :)
>>
>>
>> >
>> >
>> >> This makes no sense given that all of the properties are ALREADY
>> >> defined in the Activity Vocabulary. The Core spec deals only with the
>> >> serialization and relies on the Vocabulary document to define the
>> >> actual terms.
>> >>
>> >>> I also am still strongly against the Activity Vocabulary being a
>> >>> normative Recommendation, as it will lead to endless bikeshedding and
>> >>> its a Sisyphean task to describe all social interactions using a
>> single
>> >>> vocabulary, and the vocabulary should align where possible with
>> >>> IETF/microformats specs down to the 'string' level.
>> >>> [snip]
>> >> The Vocabulary does not attempt to define all social interactions,
>> >> just a handful of those that we know are already relevant to a good
>> >> number of existing social systems. If there are suggestions for
>> >> removing specific terms, then I'm all for looking at those.
>> >>
>> >> As for bike shedding, if the minimal set of terms defined in the
>> >> vocabulary document are not to any specific implementers liking, there
>> >> is a well defined extensibility mechanism that allows developers to
>> >> use terms from other vocabularies quite easily. Implementing support
>> >> for such extensions is fairly trivial (e.g.
>> >> https://github.com/jasnell/as2-schema)
>> > Does this well defined mechanism still work if implementation chooses to
>> > ignore JSON-LD context? I keep hearing from Harry about intentions for
>> > such practice becoming common and I would like to verify that we don't
>> > contradict ourselves here!
>>
>> Again, due to a relatively simple spec error on the part of the JSON-LD
>> editors/Working Group, @context and any other attribute defined with a
>> '@' symbol are not processed out of the box as objects by most modern
>> programming languages. Thus, you have to give any JSON-LD defined '@'
>> symbol special processing. While there it is possible everyone will
>> start  using JSON-LD libraries, I expect many if not most developers
>> will not use JSON-LD libraries but will want to consume AS2.0 as JSON.
>> It's possible I'm wrong, but that's the feedback I've gotten from
>> Thoughtworks (whose IE application is still waiting) and others.
>>
>> In other words, we need to keep JSON-LD to keep RDF interop, but realize
>> most people are not using RDF-based programming stacks. If AS2.0 is to
>> be a genuine interop layer, design needs to take that into account and
>> if JSON LD conventions are broken, c'est la vie.
>>
>>        cheers,
>>             harry
>> >
>> >
>> >> At this point in the process, it would be far more productive to focus
>> >> on implementation and fixing the specific parts of the spec that make
>> >> implementation difficult, etc.
>> >>
>> >> - James
>> >>
>>
>>
>>
>>