Re: Web Notifications

[Melvin Carvalho]

On 20 June 2012 10:58, Anne van Kesteren  wrote:

> Hi,
>
> The Web Notifications WG is planning to move Web Notifications to W3C
> Last Call meaning we don't intend to change it. But we might have
> missed something and would therefore appreciate your review of
> http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html and any
> comments you might have at public-web-notificat...@w3.org.
>


This looks really great.  Do you have an idea of who is going to adopt this
API?




>
> Cheers,
>
>
> --
> Anne — Opera Software
> http://annevankesteren.nl/
> http://www.opera.com/
>
>

Re: Call for Editor: URL spec

[Melvin Carvalho]

On 6 November 2012 09:46, Ian Hickson  wrote:

> On Tue, 6 Nov 2012, Paul Libbrecht wrote:
> >
> > Could be slightly more formal?
> > You are speaking of "hypocrisy" but this seems like a matter of
> politeness, right?
>
> I am just saying that the W3C claims to have certain values, but only
> applies those values to other people, not to itself. Specifically, the W3C
> says forking specifications is bad (and even goes out of its way to
> disallow it for its own), but then turns around and does it to other
> people's specifications.
>
> hypocrysy (noun): The practice of claiming to have moral standards or
> beliefs to which one's own behavior does not conform; pretense.
>
>
> I'm also claiming that when doing so, the W3C does not generally give
> credit where credit is due. For example, this document is basically
> written by Ms2ger:
>
>http://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html
>
> Here's the version maintained by Ms2ger, for comparison (the only
> differences I could find were editorial style issues, not even text --
> basically just that the doc has been converted from the anolis style to
> the respec style):
>
>http://domparsing.spec.whatwg.org/
>
> The most Ms2ger gets is a brief mention in the acknowledgements almost at
> the very end of the document. The WebApps working group gets a whole
> sentence above the fold: "This document was published by the Web
> Applications Working Group". The W3C has their logo right at the top and
> calls the draft a "W3C Editor's Draft".
>
> plagiarism (noun): The practice of taking someone else's work or ideas and
> passing them off as one's own.
>

^^ (citation needed) :)


>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>

Re: A very preliminary draft of a URL spec

[Melvin Carvalho]

On 13 May 2013 05:34, Charles McCathie Nevile  wrote:

> Hi,
>
> to close ACTION-693 I scribbled some stuff into a very preliminary draft
> of a URL spec:
> 
> >
>
> In the end I didn't copy Anne's spec beyond believeing him about some
> Unicode points when I was offline.
>
> So far I have done nothing at all about an API, and am waiting for some
> formal confirmation from people who implement stuff that they would like to
> standardise an API for dealing with URLs. It seems to be a common task,
> judging from the number of people who seem to have some scrap of code lying
> around for it, so I expect to hear people say "Yes, great idea" - although
> I have been surprised before.
>
> As the more astute (read " people who look at the spec for a few seconds
> with at least some level of attention") will notice, this needs work. I
> would be very pleased to receive comments that help clarify things the spec
> gets wrong, doesn't specify, or doesn't explain clearly.
>
> I hope there will be a bugzilla component really very soon, but I
> neglected to request one so far. If Mike happens to be reading, I'd be
> grateful for him to do the magic before I get around to writing the
> request. In the meantime I guess you should just reply to the thread...
>
> And no, it doesn't use futures. Sorry. At some point I will come back with
> the answer to a request for a way to change that.
>

+1 Chaals, I welcome this effort

It's tempting (especially on the whatwg ML) to think that the browser is
the web.  But the URL is used in many contexts in and outside the browser.

Please do post the link to the issue tracker when it's up, and hopefully a
some of us on WHATGW can help you and Anne in creating a stable and up to
date home for this important work.


>
> cheers
>
> Chaals
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>   cha...@yandex-team.ru Find more at http://yandex.com
>
>

Re: HTML as application manifest format

[Melvin Carvalho]

On 1 August 2013 18:57, Tab Atkins Jr.  wrote:

> On Thu, Aug 1, 2013 at 9:24 AM, Dimitri Glazkov 
> wrote:
> > On Thu, Aug 1, 2013 at 6:17 AM, Marcos Caceres  wrote:
> >> Hi Kornel,
> >> Although I have complete empathy about your criticisms regarding JSON,
> it is actually quite fit for this purpose. Using HTML in the way you
> describe is kinda problematic, in that it could include scripts and other
> resources: basically, one would need to build a DOM to parse out the
> information - and even if scripts where not run, or resources loaded, one
> would still then need to make a special HTML just for this purpose (which
> would confuse people, as if you use HTML you expect to be able to have
> access to features of the platform). We are going to need a custom
> processor for the JSON format, but at least parsing is already done for us
> (as it was with XML, though sadly it seems that devs prefer JSON).
> >
> > FWIW, I tend to think that Kornel is hitting on something here.
> > Whether we want it or not, HTML is the Web's serialization format.
> > It's the one that helps us understand where hyperlinks are and how
> > resources are interconnected. Having a manifest in that format sounds
> > like a Good Thing.
>
> HTML is the Web's serialization format *for HTML, and other text-like
> things*.  As Kornel's example shows, HTML is *not* well suited to
> holding key/value pairs or the like; you have to hack them in via ugly
>  values, and you don't get any of the benefit of the rest of
> HTML, because / *is all you're doing*.
>
> This is quite different from Templates, because those are actually
> leveraging HTML, and so using HTML as the delivery format as well just
> reduces impedance mismatch.  I don't think that applies here.  JSON is
> the way the web does key/value transmission.
>

It's rather easy these days to embed key value pairs in HTML.  10s if not
100s of millions of sites do it using rdfa, schema.org, open graph protocol
etc.

The markup need not be ugly

Often it's as simple of adding a "rel" attribute in a tag (the key), and
then the value is put inside the tag.



>
> ~TJ
>
>

Re: Are web components *seriously* not namespaced?

[Melvin Carvalho]

On 4 February 2015 at 22:31, Glen  wrote:

> I know I'm rather late to the party, but I've been doing a lot of reading
> lately about web components and related technologies, and the one thing
> that confounds me is the fact that web components appear not to have any
> "real" namespacing.
>
> Can someone explain why this is so, and what the justification is? Or is
> it just a case of "it was too complicated, this is good enough"?
>
> I see this has been brought up once before @ http://lists.w3.org/Archives/
> Public/public-webapps/2013AprJun/0964.html, but nothing changed.
>
> It's not going to be long before  has been defined by 1,000,000
> people (slight exaggeration), and you have no idea what it is or where it
> came from without looking through imports/scripts etc. Also you want to
> keep things short, so you call your element  (you work for Monkey
> Solutions LLC), but then someone else on the team is importing 
> from Microsoft, and BAM!, you have another problem.
>
> Why can't we do something like this?
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://monkey-solutions.com/namespace";
> });
> 
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://microsoft.com/namespace";
> });
> 
>
> 
> 
>
> 
> https://microsoft.com/namespace";
> prefix="msft" />
>
> 
> 
>
> You could also assign a prefix to all elements within a namespace like
> this:
>
> https://microsoft.com/namespace";
> prefix="msft" />
>
> You can override the prefix multiple times and the closest 
> definition is used.
>
> Please note that the above syntax is just an example of what could be used.
>
> Another BIG pro here is that IDEs can pull in information about the
> elements by sending an HTTP request to the namespace URI so that a tooltip
> could be displayed with an element description, author, sample usage, etc.
>
> I really do hope that it's not too late to make such a change.
>

+1 to everything

Could a colon perhaps be saved as a special character so in future you can
have  and  and the user agent would be able to work
out which code to use?


>
> Regards,
>
> Glen.
>
>

Re: Are web components *seriously* not namespaced?

[Melvin Carvalho]

On 5 February 2015 at 20:55, Tab Atkins Jr.  wrote:

> On Fri, Feb 6, 2015 at 12:48 AM, Glen  wrote:
> > So in other words it *is* a case of "it's good enough". Web components
> are
> > quite possibly the future of the web, and yet we're implementing them to
> be
> > "good enough" in "90%" of use cases?
> >
> > jQuery is JavaScript which means that it's different for various reasons:
> >
> > 1. It's less important to keep the names short.
> > 2. It's possible to rename a plug-in if there is a conflict (e.g. @
> >
> http://stackoverflow.com/questions/11898992/conflict-between-two-jquery-plugins-with-same-function-name
> )
> > 3. It's a library, not something built into the browser, which means
> that if
> > jQuery decides to add some form of namespacing, it doesn't require a
> major
> > specification and implementation by 5+ major browsers, etc.
>
> Web Components are also JS.  Any renaming you do in JS, you can do
> just as easily in HTML.
>
> >> Complicating things further simply isn't all that necessary.
> > Complicating it for the developer, or the implementers? I can't speak for
> > the latter, but for developers, this would be an *optional* feature. If
> you
> > don't have conflicts you don't *have* to alter an element's NS prefix,
> but
> > specifying the prefix in your HTML would provide rich IDE functionality,
> so
> > I don't see why anyone would *not* want to do this.
>
> Again, namespaces are nothing more than an indirection mechanism for
> prefixes, so you can write a long and more-likely-unique prefix as a
> shorter prefix that you know is unique for your page.  No
> functionality is enabled by namespaces that can't be done without them
> just as easily but with a little more verbosity.
>
> >> It's something that can be added organically as necessary.
> > Anne has already made a point about this, but also consider the fact that
> > without real namespacing, we're forced to name based on *potential*
> > conflicts. For example, in the ms- case, ms- may either already exist, or
> > *potentially* exist and be useful, so I name my element mks- instead.
> > Therefore I'm not able to give something the name that I want it to have,
> > for fear of future conflicts.
>
> Anne pointed out that XML Namespaces screwed this up, not that it's
> not easy to get right.
>
> You don't need to fear future conflicts.  Googling for a name is often
> sufficient.  You can change later if there is a conflict.
>
> > Even just being able to optionally shorten a custom element's NS prefix
> can
> > be useful. For example, if a vendor uses , we can just
> > change that to  and things will be easier to type, cleaner, etc.
> >
> > Regarding XML, I never even mentioned XML in my initial post, so I'm not
> > sure what all the fuss is about. This can be implemented in a way that
> > supports both HTML *and* XHTML/XML, yet doesn't look at all like XML
> > namespacing. The only important part is the use of URIs, I can see no
> better
> > way of providing both a unique namespace, as well as an endpoint for
> > gathering human- & machine-readable data about a set of custom elements.
> Is
> > there something inherently wrong with this? Or is this just about people
> > being too lazy to type a closing tag, because that can remain optional.
>
> Most people who mention namespaces on the web are referring to XML
> Namespaces, so I assumed you were as well.  Your suggestion is shaped
> exactly like XML Namespaces, with the use of urls as namespace, etc.
>
> >> They [XML namespaces] have a number of terrible affordances
> > +
> >> Most of them don't commit the same mistakes that XML namespaces did
> > Such as?
>
> A few are:
>
> * URLs are not a good fit for namespaces. Humans make a number of
> assumptions about how urls can be changed (capitalization, trailing /,
> http vs https, www or not, etc) which are often true for real urls due
> to nice server software, but are not true for urls, which are opaque
> strings.
> * There's no consistency in the URL structure used: some namespaces
> end in a word, some in a slash, some in a hash, etc.
> * You can't actually fetch namespace urls.  Again, they're opaque
> strings, not urls, so there's no guarantee or expectation that there's
> anything useful on the other side, or that what is on the other side
> is parseable in any way.  As a given XML namespace becomes more
> popular, fetching the namespace url constitutes a DDOS attack; the
> W3C, for example, has to employ sophisticated caching to prevent
> namespace url requests from taking down their website.
> * URLs contain a bunch of extra typing baggage that don't serve to
> uniquify anything, just make it longer to type.  The "http://"; prefix,
> for example, is identical for all namespaces (and if it's not, it's
> one more hurdle for authors to run into).  Using a string with a
> higher information content is better for authors.
> * Domain names don't mean much. For example, Dublin Core's namespace
> starts with "http://purl.org/";, which 

Re: PSA: Seeking feedback on W3C's "Modern Tooling" project

[Melvin Carvalho]

On 14 April 2015 at 14:29, Arthur Barstow  wrote:

> [Bcc public-openw3c ]
>
> Hi All,
>
> In case you missed it, last February, Robin, Philippe and others (see [1]
> for a list of contributors) started a project to "capture the state of the
> discussion about modernising the tooling that supports the making of W3C
> standards".
>
> The working document is  and the
> repository is .
>
> This is an important effort so if you have feedback, please use the
> project's Issues system  or
> submit a Pull Request .
>

I'm currently using a nice tool to document my projects:

https://github.com/csarven/linked-research

I mention it here because it has a variety of style sheets.  It can be a
regular blog post, a W3C base/draft/rec specification, or an academic paper
by clicking the menu at the top right.

It doesnt require external tooling.  Going from zero I was able to get a
skeleton up in about 30 minutes.

I find it useful for knocking out a quick brain dump, which could later
become the basis of brain storming, or specifications.


>
> -Thanks, ArtB
>
> P.S. PSA = Public Service Announcement
>
> [1] 
>
>
>

Re: Proposal - Personal Identity API

[Melvin Carvalho]

On 17 December 2015 at 13:26, Stian Soiland-Reyes <
soiland-re...@cs.manchester.ac.uk> wrote:

> Excerpts from Binyamin's message of 2015-12-12 19:50:31 +:
> > Currently many apps uses SSO (Single sign-on,
> > https://en.wikipedia.org/wiki/Single_sign-on) with different APIs and
> > protocols. It still requires server-side authentications.
> > Browsers/OSs has to validate the main personal identification data
> > (email/phone). Share the data after user acceptation similar to other
> APIs
> > like Geolocation API (demo http://html5demos.com/geo).
> > I am only wondering if it in any way could be used in save way as a
> Signin
> > authentication? Maybe by uses some encrypted validation key?
>
> You'll probably be interested to read about WebID:
>
> http://www.w3.org/2005/Incubator/webid/spec/
>
> FOAF+SSL is probably also relevant:
>
> http://www.w3.org/wiki/Foaf+ssl


FYI foaf + ssl was rebranded to be called webid:

http://webid.info/

It's now being used to power the Solid platform, I made a small gitbook
with more details

https://melvincarvalho.gitbooks.io/solid/content/

IMHO this is identity and the decentralized web done right.  Whether anyone
really still wants decentralization, I dont really know.  But I'll
certainly want to use it.


>
>
> and obviously OAuth:
>
> http://oauth.net/
>
>
> --
> Stian Soiland-Reyes, eScience Lab
> School of Computer Science
> The University of Manchester
> http://soiland-reyes.com/stian/work/
> http://orcid.org/-0001-9842-9718
>
>