Re: internationalization issues

On Fri, Oct 23, 2015 at 5:47 PM, Ben <ben@thatmustbe.me> wrote:
> map and bitcoin should probably be prefixed, but then there is
> nothing stopping anyone from producing whatever fields they like.
> That's true in any serialization.
>

And to be honest, the AS 2.0 spec **allows** terms to be used that are
not defined in the JSON-LD @context. It *does* warn developers that
doing so will make those extensions somewhat invisible/ambiguous to
implementations that do choose to do full JSON-LD processing, but such
extensions are still allowed and full JSON-LD processing is not
required.

> I know, and I find such 'prefixing' practice a concern. When people
> start defining their edu-* collab-* orga-* 'prefixes' we very likely may
> end with collisions and no way to tell if same 'JSON keys' and some
> values (eg. types) have same meaning or not.
>
> Isn't this why specs put it lines about avoiding using too many extensions
> or there may be problems with interoperability?  Also, if we don't fully process
> context, it would be even worse.  prefixing significantly reduces
> chances of collisions
> as opposed to (what i see as likely for most, and almost definite for
> me) ignoring context.
>

This is *exactly* why the spec warns implementers -- several times --
against over reliance on extensions, especially ones that overlap the
functionality of the core vocabulary. What is most likely is that if
extensions via the JSON-LD context become too cumbersome,
implementations will simply use non-declared extensions and will get
other implementations to agree on their use. That's perfectly valid
also... not ideal... but valid.

(btw, there's nothing stopping folks from coming up with normative
JSON-LD @context definitions for extensions also)

>
> James, I realized that wasn't very clear, I'm trying to write a
> service to generate AS2
> for any given url of MF2.  While you cannot override the base AS2
> context, it was more
> about generating correct context for any other data I find, just like
> elf found on werd.io
> I've never seen them, but they could be useful, I want to include
> extensions from MF2
> as extensions in AS2, but I cannot.
>

Sure you can, simply include them as undeclared extensions or simply
make up a new prefix URL for them. The spec says that extensions
SHOULD be declared in the @context and warns that interop issues could
pop up, but it does not say they MUST be.


- James

> On Fri, Oct 23, 2015 at 5:53 PM, elf Pavlik
> <perpetual-tripper@wwelves.org> wrote:
>> On 10/23/2015 11:22 PM, Ben wrote:
>>> Offhand I cannot thing of a quick link.  Most of my prefixes are in
>>> data I send from my posting app to my site, i know i use this for
>>> posting drafts to my site.
>> Could you at some point still share with us some of you custom
>> properties and possibly types?
>>
>> I noticed on http://werd.io/ use of properties
>>
>> * bitcoin (on h-card)
>> * map (on h-entry)
>>
>> Which I don't find on
>>
>> * http://microformats.org/wiki/h-card
>> * http://microformats.org/wiki/h-entry
>>
>> In bitcoin example, some people could use just the hash as value, some
>> people URI as bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W
>> https://en.bitcoin.it/wiki/BIP_0021
>>
>> Who specifies how to use 'bitcoin' property, or 'map'?
>>
>>
>>>
>>> Aaron uses his own p3k prefixes on http://aaronparecki.com/metrics
>> I know, and I find such 'prefixing' practice a concern. When people
>> start defining their edu-* collab-* orga-* 'prefixes' we very likely may
>> end with collisions and no way to tell if same 'JSON keys' and some
>> values (eg. types) have same meaning or not.
>>
>> If we drop URI based extensibility, I would like to hear clear proposal
>> for alternative strategy.
>>
>> Cheers!
>>
>>>
>>> On Fri, Oct 23, 2015 at 5:10 PM, elf Pavlik
>>> <perpetual-tripper@wwelves.org> wrote:
>>>> Hi Ben,
>>>>
>>>> On 10/23/2015 11:01 PM, Ben wrote:
>>>>> I have been working on ways to get AS2 compatible output from my site,
>>>>> and I don't think I can generate a valid context for the document as
>>>>> various terms I use on the site (some from microformats-2, some from
>>>>> IWC's wiki, and some my own vendor prefixes).
>>>>
>>>> How do you propose to handle 'your own vendor prefixes'?
>>>> Could you maybe even provide an concrete examples with ones which you
>>>> use in your data?
>>>>
>>>> Thanks!
>>>>
>>>
>>
>>

Received on Saturday, 24 October 2015 00:58:02 UTC