Singular field implementation preventing extending with namespaces

[Laurent Eschenauer]

Hi everyone,

I have an issue extending the current spec and wonder how to best go
about it. Maybe something needs to evolve in the spec to make it
easier to extend in the future. We are looking for feedback.

In our current project (http://onesocialweb.org), we want to produce
portable contacts compatible documents but also need to enhance them
with application specific information (e.g. rendering hints, privacy
settings, etc...). In the future, some of our extensions may be
interesting to bring in the standard, but this is not the focus of
this email.

So, the question is: how can someone extend PC while producing valid
PC documents. The answer could be in using namespaces. However, the
current specification of singular fields makes it impossible.

What we have now:

<birthday>0000-01-16</birthday>

What I would prefer to see:

<birthday><value>0000-01-16</value></birthday>

The later would align the singular and plural spec and, more
important, allow for construct like:

<birthday>
<value>0000-01-16</value>
<whatever xmlns="mynamspace">
... extension..
</whatever>
</birthday>

There is obviously an added complexity in JSON world with a construct
like this, but making PC easy to extend seems to me important to
encourage adoption while avoiding fragmentation of the core spec.

How would you go about this ? Feedback and suggestions would be appreciated !

Thanks,

-Laurent

[Simon Perreault]

On 2010-02-23 04:39, Laurent Eschenauer wrote:
> What we have now:
>
> <birthday>0000-01-16</birthday>
>
> What I would prefer to see:
>
> <birthday><value>0000-01-16</value></birthday>

This is exactly what we have in store for vCard 4. If you're interested,
you can take a look at the draft here:
http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-01

Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
vCard 4.0 --> http://www.vcarddav.org

[Joseph Smarr]

Laurent-thanks for the question. We debated this when making the spec, but consciously chose to keep singular fields "simple" (no nested structure) because we couldn't think of a lot of valid use cases for extending them (you wouldn't normally do <birthday type="work"> for example, the way you would with say a phone number), and we really wanted the wire format to look simple and easy-to-understand. The type of extensibility you suggest is definitely possible and correct today for plural or complex fields (e.g. phoneNumbers or organizations), but if you need to do something similar for singular fields, your best bet is to define a new parallel field, such as <birthday-whatever> or <whatever><birthday>...</birthday></whatever>. That may seem hacky at first, but since this is extra data beyond the core spec, clients will need custom logic to know where to look for it anyway, so as long as you define a simple and consistent rule for dealing with singular fields, you'll be fine. I might suggest the latter strategy, since you can them encapsulate all your extra metadata in one place--in other words, you'd have normal PoCo plus an extra payload with more info that can be processed all at once.

Hope this helps, thanks! js

--
You received this message because you are subscribed to the Google Groups "PortableContacts" group.
To post to this group, send email to portable...@googlegroups.com.
To unsubscribe from this group, send email to portablecontac...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/portablecontacts?hl=en.

[Kevin Marks]

I agree with Joe here, and would add that considering the JSON as primary and the XML as secondary syntax is the best way to think about the PoCo standard. If you come up with something that makes a mess of the JSON flavour, you're missing the spirit of the spec.

On Feb 23, 2010 9:16 AM, "Joseph Smarr" <jsm...@gmail.com> wrote:

Laurent-thanks for the question. We debated this when making the spec, but consciously chose to keep singular fields "simple" (no nested structure) because we couldn't think of a lot of valid use cases for extending them (you wouldn't normally do <birthday type="work"> for example, the way you would with say a phone number), and we really wanted the wire format to look simple and easy-to-understand. The type of extensibility you suggest is definitely possible and correct today for plural or complex fields (e.g. phoneNumbers or organizations), but if you need to do something similar for singular fields, your best bet is to define a new parallel field, such as <birthday-whatever> or <whatever><birthday>...</birthday></whatever>. That may seem hacky at first, but since this is extra data beyond the core spec, clients will need custom logic to know where to look for it anyway, so as long as you define a simple and consistent rule for dealing with singular fields, you'll be fine. I might suggest the latter strategy, since you can them encapsulate all your extra metadata in one place--in other words, you'd have normal PoCo plus an extra payload with more info that can be processed all at once.

Hope this helps, thanks! js

On Tue, Feb 23, 2010 at 1:39 AM, Laurent Eschenauer <laurent.e...@gmail.com> wrote:
>

> Hi e...

--
You received this message because you are subscribed to the Google Groups "PortableContacts" gro...

[Joseph Smarr]

Simon-and it's also one of the things we need to reconcile so we can get your spec and PoCo aligned! :) It's always "easy" to say "let's just add more room for extensibility", but just as "speed is a feature" that's easily lost if you don't actively protect it, so is simplicity. So please consider the advantages we were optimizing for by *not* doing what is proposed in vcardxml 4...

Thanks, js

--

[Simon Perreault]

On 2010-02-23 13:59, Joseph Smarr wrote:
> Simon-and it's also one of the things we need to reconcile so we can get
> your spec and PoCo aligned! :) It's always "easy" to say "let's just add
> more room for extensibility", but just as "speed is a feature" that's
> easily lost if you don't actively protect it, so is simplicity. So
> please consider the advantages we were optimizing for by *not* doing
> what is proposed in vcardxml 4...

I very much understand your concern. My first attempt at a vCard XML
schema was similar to yours. However, the working group decided to add
data type elements for a number of valid technical reasons. The working
group needs to be convinced, not me.

Note that this is aligned with the direction where iCalendar is going:
http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-01

[Laurent Eschenauer]

Thanks Joseph, Kevin, for replying and explaining this design choice.
I fully understand them, giving the focus on JSON and specific use
cases you are dealing with.

Another hack could be this one:

<birthday>0000-01-16</birthday>
<birthday xmlns="whatever">extension stuff in here</birthday>

But indeed, these are just hacks. So we'll have to think through this
and maybe use or define another model internally, and eventually
expose some data in PoCo through a REST API.

Thanks Simon for the vcard4 proposal, I'll definitively have a look at it.

> It's always "easy" to say "let's just add
> more room for extensibility", but just as "speed is a feature" that's easily
> lost if you don't actively protect it, so is simplicity. So please consider
> the advantages we were optimizing for by *not* doing what is proposed in
> vcardxml 4...

I personally think that extensibility is key to adoption and survival
of a standard. It enables to standardize the core, while letting
developers experiment at the edges. These experimentations then
eventually get standardized.

I also don't see how wrapping singular values into a <value/> element
is a threat to simplicity. In fact, it would simplifies parser design,
a basic parser would not need to have to differentiate between
singular and plural fields anymore.

But then again, I look at it in a XML way, and it seems that JSON is
the primary focus of your work.

Cheers,

-Laurent