[uf-discuss] A question about the "locality" property in hCard microformat
Hi everyone, I've run into a bit of a problem with the locality property in hCard microformat with large companies in Finland. Large companies in Finland can get their company name as their "locality" in their mailing address. I've worked with the Finnish national broadcasting company YLE (the Finnish equivalent to the BBC) in the past and suggested they use the hCard Microformat in their global footer to display their address. They've started to do so, but Microformat parsers get the address wrong because of this locality issue. Should it be even marked as "locality" because it's not an actual location any more? Operator for example gets it wrong when trying to a find the address on Google maps. Could the solution be to add the "org" property as a secondary classname to the locality resulting in "locality org"? Live example from http://www.yle.fi --- Yleisradio Oy, Radiokatu 5, 00024 Yleisradio, puh. (09) 14801 --- Possible solution with two properties locality + org ? --- Yleisradio Oy, Radiokatu 5, 00024 Yleisradio, puh. (09) 14801 --- br, Janne ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Precise Expansion Patterns
This would be acceptable: 3 seconds Or if we wanted to use the hMeasurement approach: three seconds two minutes, three seconds two years, 35 hours three seconds this kind of thing would: 1. add complexity to parsers 2. require people to be very precise in the choice of allowed strings ... eg: "year" or "y" , "second" or "seconds" otherwise dates and times may very quickly degenerate into something not much better than garbled freeform text dates. It would also mean a lot more rules for authors to remember which could result in a lot of invalid markup being published. If dates/times are no longer machine-readable I would see no longer see much practical use for any of this! I am very wary of straying too far from ISO for dates and times (or at least something that can easily be parsed by javascript/php/perl/ruby/whatever built-in date functions or commonly used date libraries) keep it simple ! ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] is job-listing a kind of hlisting?
On Dec 17, 2007, at 4:14 PM, Klaus Mueller wrote: do you also think http://microformats.org/wiki/job-listing is or should be a kind or defined undergroup of http://microformats.org/wiki/hlisting ? It was at one point. I split it off on the "solve a specific problem" principle. Other than the word "listing," there's very little in common between a job listing and, say, a computer for sale. Labeling a salary with "price" isn't really accurate, and most of what you'd want to describe about a job in hListing is that same kind of jamming information into a field where it doesn't really belong. But I'm no longer working with job listings, so my opinion isn't particularly relevant anymore. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] is job-listing a kind of hlisting?
Hi all, do you also think http://microformats.org/wiki/job-listing is or should be a kind or defined undergroup of http://microformats.org/wiki/hlisting ? greetz klml ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Precise Expansion Patterns
Benjamin Hawkes-Lewis wrote:
>>
>> http://www.w3.org/TR/html401/struct/global.html#adef-title
>>
>> title = text [CS]
>> This attribute offers advisory information about the element for
>> which it is set.
>>
>>
>> However, I do agree that "PT2M23S" is stretching the rules a bit.
>
> Can information that "readers are probably not going to understand" be
> classed as "advisory"?
We could argue it both ways based on how we define "advisory" and the
pattern recognition and cognitive abilities of the general Internet
population. Since we have a potentially better solution on the table,
let's not go down this path yet.
> What I was proposing was this. When all the information required is
> available in the content of the element in Arabic numeral form, and all
> a parser would need to know is what units are being used, we should
> prefer to mark up the units rather than attempt hide an ISO format of
> the same data with the TITLE hack.
Agreed.
> So, to adopt your milliseconds example, we could avoid TITLE and just use:
>
> 2
> milliseconds
Sure, we could do that... although, we should be careful to address all
of the problems... we would still need to address some of the
non-standard cases that you outline below.
> We might prefer to specify abbreviations like s and ms, I'm not sure.
If we're going to put "s" and "ms" in @class, then I don't think that
would be a good idea. If we were to, however, place that information in
title... that would be fine, IMHO. To illustrate:
This would be a bad idea:
3 seconds
This would be acceptable:
3 seconds
Or if we wanted to use the hMeasurement approach:
three seconds
two minutes, three
seconds
two years, 35 hours
three seconds
> Obviously, if this principle were to be extended to other sorts of
> measurements, it could get more complicated for two reasons:
Take a look at the hMeasurement strawman... there's been a great deal of
thought put into the issues that you describe:
http://microformats.org/wiki/measure-brainstorming#Straw_man
> 1. People might want to use variations on the SI units that cannot be
> expressed with the SI prefixes e.g. 10^26 s.
We can do this if we use hMeasurement:
10^26 seconds.
> 2. People might want to use non-SI, non-global units like inches and
> quarts.
Then they will need to convert it to SI units:
15 stones
> Now, it might be that we could adapt the principle to serve in some of
> those situations too:
>
> 1. Perhaps we could allow class names like "seconds/10^26" (it's ugly
> but legible and conforming).
We can already do this in hMeasurement:
10^26 seconds
Or, alternatively they could convert it to another representation format:
10^26 seconds
> 2. Perhaps we could think about specifying class names for widely-used,
> non-SI units like inches.
Like this (in the current hMeasurement proposal):
four feet, four inches
> 1. Obscure units ("5 chains wide")
Boiling the oceans - we should make them convert it into a more popular
measurement.
> 2. Use of non-Arabic numerals ("III HORA")
Boiling the oceans - make them convert it into a more popular measurement.
> 3. Use of words instead of digits ("three seconds long")
I think addressing this was outlined above.
> 4. Fuzzy representations where not all the information required is
> implicit in the human-friendly content ("about three miles")
There is room for error metrics in hMeasurement too, although, it hasn't
been worked out quite how we do that.
> For these cases, we would /still/ need an expansion pattern. I wasn't
> particularly thinking of the expansion pattern you suggest, since it's
> still attempting to put tortured data-showing requirements over the
> needs of human end-users.
Do SI measurements constitute "tortured data"? Is displaying "2min 23s",
or "2 minutes 23 seconds" better than displaying "PT2M23S"?
> The point of my suggestion is to reduce the number of cases where we
> need an expansion pattern, since expansion patterns are proving
> problematic.
Let's address the actual problem of precise expansion patterns for
measurements.
So we could do one of the following:
1. Use hMeasurement and add "h for hours" and "y for years".
2. Define "second", "minute", "hour", "year" classes.
3. Create "second", "minute", "hour", and "year" aliases in to the
hMeasurement units "s", "min", "h", and "y", respectively. Use
hMeasurement.
I suggest doing the 3rd thing, which would give us all of the following,
valid, markup:
2 minutes 23 seconds
2:23
2 minutes, 23 seconds
2:23
This approach is more of a measurement design-pattern, but solves the
accessibility and usability issues surrounding using ISO8601 and a
variety of the other ISO formats for measurement.
-- manu
___
microformats-discuss mailing list
microformats-di
[uf-discuss] Possible vCard Revision; CalConnect involvement
Dear Folks, I'm Dave Thewlis, the Executive Director of CalConnect - The Calendaring and Scheduling Consortium. Andy Mabbott suggested that I cross-post to this list as there are people in the microformats world interested in vCard (and in calendaring, for that matter). Unfortunately I managed to space doing it until just now. Fortunately, I have something additional to add to the post that prompted Andy's suggestion. The subject is a revision to the vCard specification to be undertaken by the IETF, and whether CalConnect will undertake a technical committee to do use cases, requirements, promotion, interoperability testing, and the likem in support of that work. (1) Here is my posting to the CalConnect lists that prompted Andy's suggestion, dated November 5th: Seven weeks ago we held our vCard workshop. Two of the outcomes were (a) that Chris Newman from the IETF thought he saw strong enough support for doing a revision of vCard that he was going to start movement in the IETF towards a working group to this end, and (b) CalConnect would initiate a vCard Technical Committee IF it could find resources to support the committee. This essentially meant new people from existing members and/or people from new members, as the current volunteers are pretty well maxed out. CalConnect was to post a draft charter for a vCard TC on the vcard-workshop-l list (the public list we set up to support the workshop). Interested parties were encouraged to offer help, either on the vcard-workshop-l list, or directly to me. If we could not find anyone to do the work (usecases, requirements, possibly IOP test development, and promotion) then there was no point in going forward. The draft charter was posted a month ago. There were two replies. Since then nobody has said anything especially about volunteering to help. Therefore, this e-mail is a "final" call for action. If you or your organization is interested in actually seeing something positive happen about a vCard revision, *please* speak up - on the vCard-workshop-l list, or to me - and let me know. We need a few TC participants. And we need some organization to step up and offer a Chair for the TC. And we could use a person or two to help with writing whatever documents we produce. Here is a chance for an organization with a serious interest in seeing something good happen with vCard and who isn't a member to step up, get involved, and take a leadership role. But if you are interested, if you can help, if you can just attend the occasional call and read a document, let us know. Even if you are an existing participant, if you think you could put a bit of effor into this, we wouldn't deny you the opportunity :-) If we do NOT get any responses, then we must conclude that there is still not enough interest to actually do something about a vCard revision -- and we will table the idea. Hoping to hear from you! --- (2) Here is a follow-on posting from yesterday, December 16, on the current status of vCard issues: The IETF has approved a charter for a vCard Working Group and sent it to the IESG for approval, and work has begun on updating and republishing the existing vCard draft. This means that there should be a vCard Working Group initated, or a vCard BOF, at the March IETF meeting, with documents to consider. In turn, this means it is time for CalConnect to start forming its vCard Technical Committee to inform the IETF working group. A proposed charter for this TC was circulated on the vcard-workshop-l list some weeks ago, and may be found at the following URL (near the bottom of the page: http://www.calconnect.org/vcardworkshopreport.shtml We have had some interest expressed in working on this issue from CalConnect members and from others, and it's time to decide what we are gong to do going forward. *We plan a public (open to members and nonmembers) conference call for: Friday, January 11, 2008 at 1100-1200 Eastern (0800 Pacific, 1600 U.K., 1700 CET). Call-in information: Phone #: +1 605 990 0100 Confid: 879307#* Please join us on this call if you are interested in seeing the vCard specification move forward. We'll talk about current status since the workshop, the charter we have proposed, and plan to identify participants for a CalConnect Technical Committee to work in conjunction with the IETF WG. Please feel free to pass this e-mail on to others who would be interested in the subject, and encourage them to attend. - So we are going to have that call on Friday, January 11th, and anyone interested in vCard is welcome to attend. Meantime, you are also welcome to join the vcard-workshop list mentioned above: see http://www.calconnect.org/vcardworkshoplist.shtml This list might be
Re: [uf-discuss] Subject tagging
On 17/12/2007, Andy Mabbett <[EMAIL PROTECTED]> wrote: > People wrote: > > >Re: [uf-new] [Fwd: Re: [uf-discuss] Re: Precise Expansion Patterns] > > Please, everyone, remove "[uf-discuss]" from subject lines when moving > threads to uf-new (and vice versa); since people sort mail into folders, > based on those tags. Umm, wouldn't it make more sense to sort based on either the To: or the List-Id: headers? the List-Id: for this list is: List-Id: Microformats Discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Subject tagging
People wrote: >Re: [uf-new] [Fwd: Re: [uf-discuss] Re: Precise Expansion Patterns] Please, everyone, remove "[uf-discuss]" from subject lines when moving threads to uf-new (and vice versa); since people sort mail into folders, based on those tags. -- Andy Mabbett ** via webmail ** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Precise Expansion Patterns
Manu Sporny wrote:
Paul Wilkins wrote:
[snip]
I consider the following to be bad
2:23
Agreed. This is hiding data.
So is putting anything in the TITLE attribute on a non-empty element.
Sure you can get some UAs to show it by hovering over it (although it's
generally hard to trigger such tooltips with the keyboard alone). But
then you could also get your browser to show the data in the ABBR
example above by viewing source (or using a tool to show all TITLE
attributes, or indeed all microformatted data).
Then there's the SPAN element. This one too has issues with the title
text, in that anybody seeing it isn't likely to understand its
meaning.
2:23
It appears that when the title text is used on content, it must must
remain as a human-understandable construct.
Agree with the first part, readers are probably not going to understand
PT2M23S. Disagree with the last statement, this is not in violation of
the HTML spec, IMHO:
http://www.w3.org/TR/html401/struct/global.html#adef-title
title = text [CS]
This attribute offers advisory information about the element for
which it is set.
However, I do agree that "PT2M23S" is stretching the rules a bit.
Can information that "readers are probably not going to understand" be
classed as "advisory"?
Just to go back to a previous e-mail in the day... I don't think I fully
understood what Benjamin was proposing with the following:
2:25
After looking at it again and running it through a variety of tests,
it's looking like a fairly good solution to the issue... very verbose,
but it doesn't have any of the previously stated problems
(accessibility, usability, or tag abuse), and there are several more
benefits that it brings. For example, you can do this:
twominutes and
43 seconds
For an example of how this looks, check out #6 on the following page:
http://uf.digitalbazaar.com/unit-tests/sandbox/isodata.html
You can also do stuff like this, for fractional elements:
2 milliseconds
In fact, if we had the following Microformat:
duration
year
month
day
hour
minute
second
We could address not only duration, but also specify time (January 15th,
2008):
January
15th,
2008
This line of reasoning follows what we've been doing with hMeasure:
http://microformats.org/wiki/measure-brainstorming#Straw_man
Was this what you were getting at, Benjamin?
Sort of.
What I was proposing was this. When all the information required is
available in the content of the element in Arabic numeral form, and all
a parser would need to know is what units are being used, we should
prefer to mark up the units rather than attempt hide an ISO format of
the same data with the TITLE hack.
So, to adopt your milliseconds example, we could avoid TITLE and just use:
2
milliseconds
Units we might want to specify for duration would include:
years
months
days
hours
minutes
seconds
Second is the SI unit for time. As such, you can append the 20 standard
SI prefixes: from yotta- (10^24) to yocto- (10^-24):
http://en.wikipedia.org/wiki/SI
We might prefer to specify abbreviations like s and ms, I'm not sure.
This makes for simple implementations in the case of durations, since
these units seem to be in global use.
Obviously, if this principle were to be extended to other sorts of
measurements, it could get more complicated for two reasons:
1. People might want to use variations on the SI units that cannot be
expressed with the SI prefixes e.g. 10^26 s.
2. People might want to use non-SI, non-global units like inches and quarts.
Now, it might be that we could adapt the principle to serve in some of
those situations too:
1. Perhaps we could allow class names like "seconds/10^26" (it's ugly
but legible and conforming).
2. Perhaps we could think about specifying class names for widely-used,
non-SI units like inches.
So cases that could not be covered by this principle include:
1. Obscure units ("5 chains wide")
2. Use of non-Arabic numerals ("III HORA")
3. Use of words instead of digits ("three seconds long")
4. Fuzzy representations where not all the information required is
implicit in the human-friendly content ("about three miles")
For these cases, we would /still/ need an expansion pattern. I wasn't
particularly thinking of the expansion pattern you suggest, since it's
still attempting to put tortured data-showing requirements over the
needs of human end-users.
The point of my suggestion is to reduce the number of cases where we
need an expansion pattern, since expansion patterns are proving problematic.
--
Benjamin Hawkes-Lewis
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Precise Expansion Patterns
Paul Wilkins wrote: On 12/16/07, Michael MD <[EMAIL PROTECTED]> wrote: what about html5's datetime attribute? (would only be of use in html5 though) There is a datetime attribute (on a very select few elements) in HTML4. The trouble is that you are required to specify a full date/time, of which only one type for format is accepted, which is too narrow for our needs. I presume that there are similar issues with the HTML5 standard too. Yes, the TIME element with the DATETIME attribute in the HTML5 /draft/ (it's not a standard yet!) is not a duration, but a specific point in time: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-phrase.html#the-time http://www.whatwg.org/specs/web-apps/current-work/multipage/section-common1.html#dates -- Benjamin Hawkes-Lewis ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
