Timestamps are in UTC.
Can anybody point me to some good examples of vCards?
Want to make sure i'm structuring mine properly
mwunsch There are plenty in the wiki hcard-examples
http://microformats.org/wiki/hcard-examples-in-wild
csarven: thanks
hey tantek: trying to get Julian to join...
hey manu
ok I have an unrelated question, how is http://to./ a valid URL, and what is the TLD?
While we wait, here's the HTML WG issue that is related to @profile in HTML5: http://www.w3.org/html/wg/tracker/issues/55
looks like .to is the TLD?
Hi Julian :)
good evening :-)
Togo?
appears you're too late
ok then
Tonga
O I c
Tonga TLD == .to, but still no idea why http://to./ works
anyway, @Profile.
Julian, we're discussing ISSUE-55, right?
Tantek's proposal has the nice property of not requiring the support of a certain set of people.
in the HTML WG tracker?
I think RDFa community would support @profile everywhere.
yes, that's the issue
we may process it differently, but from what I understand, that would be fine.
so if we made this a stand-alone spec
we'd also allow it everywhere - so we would go beyond what HTML4 said
right?
reschke - I don't really see any political aspects as a strength or weakness - I'd rather focus on the technical and documentation merits.
tantek - here's the previous @profile proposal that we worked on: http://html5.digitalbazaar.com/specs/html5-epb.html
sure, but I've had enough of politics over the last seven days, so less controversy sounds good to me
It was just an attempt at a proposal... but that is the form we're thinking about, right?
I think the idea is worthy on its technical and architectural merit
manu - haven't had time to review your draft. I was envisioning something simple starting from what I wrote up for XMDP.
If it wasn't we wouldn't be discussing it
and then extending that to every element
but HTML WG has a difficult history... so we need to at least be aware of that going forward.
So Manu's "old" document has @profile for <head>, link/@rel=profile, and "my" HTML 4.01 erratum
manu - I'd rather proceed forward with assumption of good faith.
would it make sense to use that as a staring point?
...starting...
tantek: yes, we're proceeding with assumption of good faith.
yep
I'd rather start with XMDP and extend it to all elements
which brinngs us to the question - *where* do we want to do that
here's what I'm concerned about: if we miss the deadline for @profile response.
that takes @profile off of the table
It's fairly minimal and neutral
not only for HTML spec, but for any future separate spec, IIRC.
I think we need to be able to communicate a plan
manu - I disagree - it takes @profile in the core HTML5 spec off the table
which I think is fine
Maciej just argued that just because something is split apart, or put together in the HTML5 spec, it doesn't change the scope of what the issues apply to.
Manu - RDFa-in-XHTML doesn't use @profile, right?
RDFa in XHTML /does/ use @profile.
but it's a SHOULD, not a MUST.
but doesn't require - right
I think the problem is with abstract extensibility being in the core HTML5 spec
ok, so from that point of view it would be a spec that RDFa-in-HTML would want to cite, right?
I agree with the sentiment and want that to be the way it is, Tantek - but we just had something happen in HTML WG that demonstrates that the chairs may not agree with us.
perhaps - not clear that dependency is necessary
manu - I'm confident that reasonable proposals made in good faith will be listened to
I'd really like to minimize any rhetoric otherwise
ok
which makes Tantek our spokesman :-)
I'd be fine with that.
so...
similarly, I'm also fine with posting the profile on any element proposal as a draft on microformats.org
and contributing it to HTML WG
or you Julian - I'm slammed at the moment, so shouldn't be in the critical path for this.
are we going to say: "yes we're doing a change proposal", but it involves creating a separate spec?
since that's a pattern that is simi?p"to specs being posted on WHATWG and being contributed to HTMLWG
this isn't a change proposal though
that's the point
this is a separate spec
understood
but I think Manu is right...
I actually like the idea of keeping HTML5 more minimal
...in that letting the date slip away may weaken the position for adding it as a separate spec.
but then
this would be a spec with 3 independant supporters
also true.
so Sam's rule should apply
and we're *certainly* in scope
as we're just saving/extending something that is in HTML4 and in use
so separate spec it is?
yes
Julian - we're good if we just ask for an extension and say that the three of us are working on a proposal.
sure
just to cover our bases.
I can send email for that
great, thx.
manu, I generally agree with section 3 HTML 4.01 Errata in your draft, as that seems compatible with XMDP
do we want to talk about the venue where to write the spec?
and the level of detail is appreciated
I personally don't care.
I'm not sure about the first part though
I'd prefer not to have to drive it, but would certainly contribute stuff and moral support
I'm not tied to the first part in any way.
ok
I didn't try @profile everywhere because there didn't seem to be support for it in HTML WG.
and we were going from no @profile, to @profile back in head.
I've been transitioning and updating/errating XMDP to the microformats wiki overtime, and this is a good reason to generalize that and expand it to permit more flexible processing
going from no @profile to @profile everywhere might have freaked people out.
it was discussed shortly and I think there was some sympathy for making it more useful if it reappears
so it might be exactly the opposite
manu - I agree that profile everywhere might "freak some people out" but that's only in the core spec IMHO
so...
reschke - I think that's true too - the key is to document a very good processing model
I tried to do that starting with XMDP
so
but clearly there is an expectation of more details with HTML5
- we don't want to touch HTML5 core
tantek: the question of validation will come up - is @profile everywhere valid for HTML5 UAs?
- we want to publish in the HTML WG
I say that it is valid.
- but we need some more time?
or rather, we want to agree that dropping "profile" from HTML5 head element makes sense at this time given current usage
it is as valid as Microdata or RDFa
reschke: yes.
...or it would be...
manu - regarding validation, ask the same question of microdata or RDFa
or any extension
you should get the same answer
right
tantek: yes, exactly my point - the answer is "we haven't figured that out yet"
manu - and that's ok for a spec in progress
just express a desire that validation works similarly for such extensions
I'm still not 100% happy about this (validation) in conjuction with the text/html re-reg, but that's a different battle to fight (different issue and change proposals)
it would put more pressure on the HTML WG to figure it out.
because that seems to make sense, place them on similar footing, similar understanding for authors etc.
absolutely
right
We've been trying to get that answer out of HTML WG and WHAT WG for a while now.
I'm ok with the folks who care about validation driving the need to figure out exactly how validating extensions works
that would be Henri
I think they'll have to figure out a way that is fairly equivalent for all extensions
who has written validators for both RDFa and Microdata.
and Mike Smith, actually
oh, did he?
I believe he did... last I checked.
RDFa (without CURIE support) was definitely in there
but they aren't hooked to validator.nu right now, as far as I know
and it was experimental.
ok
so separate spec
Tantek, do you have text that we could use?
in the separate spec.
so do we want to include the link relation? It wouldn't be needed for HTML then, but might be useful in other places?
I say keep it out for now.
unless we have a clear use case for it.
right, I trust them to be critical but do the right thing from a technical perspective, which I think is correct.
manu - what do you think should be the scope of this document?
might be a good candidate to test the IANA registry when it's there
should we simply propose profile as an extension to HTML5
but can of course be defined separately
or also include an informative errata for HTML 4.01?
1) yes
2) I think it would be good to have that erratum published somehwere
or also include an informative extension for HTML4.01 (similar to how ARIA extends HTML4/XHTML)
tantek: scope should be simple - proposal profile as extension to HTML5, propose that @profile be allowed everywhere.
...but it appears the W3C isn't looking towards opening that can of worms
In other words, I don't see a need to tie "profile on any element" to requiring HTML5
does that make sense?
oh ARIA does? Then we might want to do that as well
hrm.
that makes a lot of sense; it would be great to have this in HTML4
I would agree with keep the link relation *separate*
i'd like to continue to evolve rel-profile here: http://microformats.org/wiki/rel-profile
does it add complexity? (doing it for all of HTML)?
i'm fine with that
I'm concerned about addressing too many things with this draft.
ok, so let's park the link relation for now
I'm definitely concerned about saying anything about "fixing HTML4"
reschke - I don't think it adds complexity
manu - hence why I suggested *informative* errata
for HTML 4.01
so informative erratum for HTML 4.01 for head/@profile
if it's informative, Maciej will question why it's in the spec at all... since it seems to be a conformance requirement for HTML4.01
thus if someone ever decides to do a HTML 4.02 or HTML 4.1 that *just* fixes HTML 4.01 (no new features) then they could incorporate it
and an extension for HTML in general for @profile everywhere?
reschke - see how ARIA does this
tantek: yes, I do see the positive benefit of it.
ok
I think there's no problem keeping the erratum (it's ready anywhere); in the worst case we can still drop it.
the point is that something doesn't have to be normative right away in order to eventually have a potential positive impact
true
the erratum that Manu wrote up is pretty good already
maybe we should just post it as attachment on www-archive so it get's a stable URL for now...=
?
I would only suggest/make editorial changes
Ok, so we're talking about this spec having two things: @profile everywhere proposal, HTML 4.01 Erratum.
informative HTML 4.01 erratum
errata - sorry - since they are plural :)
right
something that we can point people to when they complain about the HTML4 spec
and possibly a third, informative use of profile in HTML4, similar to use of ARIA in HTML4/XHTMl1
reschke - right
it's also a useful base for talking about @profile in HTML x with x > 4.01
and if the people that are concerned about HTML4 want to take the informative errata and push them to be normative - that can be done later and indepenently
ok then
ok
proposal: I'll put together a mail, and let you review it, then send it to the mailing list
unless somebody volunteers
I think we can start drafting on microformat.org/wiki as soon as time permits us
we can also hop over to etherpad and do it together.
that sounds good, you get the e-mail ready
http://microformats.org/wiki that is
proposal: I can edit/merge text for the proposal and put it in a form that HTML WG will accept.
I can do a rough draft with combining of XMDP and Manu's HTML 4.01 errata
if there is no objection
tantek: I'll need suggestions, edits, text from you
great
no, that sounds perfect.
order of operations:
manu - would you be ok with us developing/iterating this draft on the microformats wiki?
that would be fine
you're a part of HTML WG, Tantek?
from which we can ship snapshots to HTMLWG as needed?
manu, yes
ok, good, no IPR issues then.
tantek: sounds like a plan.
not only that, but just as WHATWG has a better copyright license that W3C, so does microformats.org
WHATWG uses MIT license, microformats.org uses CC public domain + CC0
this is a good thing
I think many folks will express sympathy with this style of spec development
1) Julian drafts e-mail to HTML WG, Manu and Tantek review, give feedback. Julian sends @profile e-mail to HTML WG.
2) Tantek and Manu edit uF wiki with spec text.
3) Manu puts a snapshot of spec text on uF wiki into a format that HTML WG will be okay with.
Question about Vcards, is there a vCard validator? I've exported a vcard from my parser, and it looks totally correct, but apple says 'No importable cards found'
ok, so just so I can start a stub, would /wiki/html5-profile be ok? or alternative short name suggestions?
tantek: that works for me.
html-profile?
no 5?
mwunsch - yeah, vCard validation is a problem
reschke - I suggest the 5 just to show the focus
hrm, no 5 would be good if we intend this to apply to HTML4.01 as well.
the normative bits apply to 5
tantek -- It's odd: Apple recognizes this as a vCard, I am able to view it as a vCard in Quick Look; but I am unable to import it into my address book
manu: http://etherpad.com/cUatuLNdYH
it's fine to have the informative errata in the same document that applies to previous versions of HTML and XHTML
mwunsch - that is very odd - have you tried converting the same hCard using H2VX and looked at the vCard it produces?
do a file comparison?
let me try that
ok, I have to run - anything else before I leave?
manu - ok I'll start drafting it. unless there is objection, I'll put you down as co-author and myself as editor for now.
do we want to give an estimated ETA for a first draft?
man, I love etherpad. Start it, write a sentence, and let other people do the rest.
that was a trap, wasn't it.
always
but then it's evening over here, and I already had my first beer.
Should I send this?
looks good to me
tantek?
...pasted into email to the two of you, in case Tantek is away
he's probably already drafting
here
just doing some wiki editing
reschke - first draft (not complete) but posted: http://microformats.org/wiki/html5-profile
superb
maybe we should put that into the email as well?
nah - I think it's too incomplete to be worthy of the HTMLWG's attention at this time
the curious folks will find it
I'm editing the etherpad with a few more details
right
do we need to promise when a FPWD will be ready?
i think we should give an *estimate* for something that could be ready for FPWD.
how about we just say that a draft x n progress on the microformats wiki for those who are curious.
my experience is that it usually takes at least as long as we plan for.
hey guys
and say that we don't have an estimate for when a FPWD will be ready.
three weeks for an initial proposal should be ok
hey manu
reschke - SXSW is in 3 weeks and I will be unable to commit to that
The only concern I have is giving people a reason to question the work.
I'll commit to 3 weeks from now.
if it's five week i'll be ok as well
I'd rather say that we don't have a specific date for when a FPWD will be ready, but if there are f3 that are interested in seeing something sooner please speak up.
if all it entails is copying text verbatim from uF wiki to HTML WG spec.
As long as it's clear that the three of use commit ourselves to do this.
tantek: I'm fine with that as well.
just saying that we're actively working on it in the open I think is sufficient
that way people that care can read updates as they wish
without waiting for a FPWD
and that also removes the need to commit to a particular date
I'd rather push for a FPWD when we feel the contents are worthy, than a specific date.
yes, and we want to encourage (constructive) discussion anyway
and transparent development
I'm ok with both.
ditto
I think we should give /some/ idea of how long we think this is going to take, though.
we don't want to leave it open ended.
especially since we're asking for an extension.
we're not asking for an extension
something in between
:-)
we should be very clear we are ok with amicably closing the issue
that shows good faith up front
Can we say "by the end of March" and be done with that?
we can say we hope to have a FPWD by the end of March, but will only propose it if we think the contents are worthy of it by then.
we should make sure that by amicably closing the issue that we don't shut the door on @profile in any spec published via HTML WG first
we don't because this is new information
profile attribute on all elements is new information
manu: yes, that's why we're sending this proposal in the context of ISSE-55.
I'm really not worried about door closings like that
We should make sure that the chairs agree with us.
why? I think the chairs are reasonable
I think by sending feedback in time we're ok.
I don't think we need to worry about that frankly
we shouldn't ask anyone to agree with us in advance for a proposal etc.
I don't think that's reasonable
hrm, I think there is some miscommunication going on here.
no, we don't ask for agreement; we just announce our plan.
I think that we should very clearly state our plan.
right.
better to just say something like, we consider the generalization of the profile attribute to all elements to be new information and outside the scope of this current issue.
I'd be fine with that.
that would give anyone the opportunity to respond if they don't think that is the case.
that way, we're clear what we mean, and transparent with future plans
right
much better to express expectation of good faith of other participants rather than attempt to bind people into agreeing IMHO
we are in violent agreement.
I think in general the chairs tend to look more favorably upon folks who help encourage more civil discussions/culture/community in the working group.
Plus I think it helps set a good example.
yup
so, that clause should be added to the e-mail Julian.
so one more edit to the mail?
I've been editing the etherpad directly - can we update there?
sure, that was the point
manu - feel free to add scope and FPWD expectations language per the above
tantek: The problem was, i was saving my output as .vcard, not .vcf
Not sure...why that was causing an issue though
But HMachine can successfully convert hcards to vcards
:-)
pushing to github now
woohoo!
thanks mwunsch
thanks manu and reschke - I think the html5-profile proposal is a good idea for many reasons
a few more minor updates - but definitely in need of more work:
http://microformats.org/wiki/html5-profile
These logs were automatically created by mflogbot on chat.freenode.net using a modified version of the Java IRC LogBot.
See http://microformats.org/wiki/mflogbot for more information.