[uf-new] Revisiting grouping problem solution proposal: hset
martin at weborganics.co.uk
Thu May 17 14:29:59 PDT 2007
On Thu, 2007-05-17 at 13:47 -0400, Manu Sporny wrote:
> Martin McEvoy wrote:
> > On Wed, 2007-05-16 at 14:00 -0400, Manu Sporny wrote:
> >>> "using brief, descriptive class names"
> >> hset is a brief descriptive class name, isn't it?
> > Yes hSet is descriptive
> > my trouble lies in what comes after, you are asking users to invent
> > their own class after that ie, hset.whateveralbum.whatever_track, how do
> > you know that I won't name my class hset.xtre.wefutr or something
> > equally meaningless, you wont know what this means and neither will I,
> > what you propose only has meaning to the user, and no simple naming
> > convention.
> Ahh, I finally understand your point (forgive my thick skull). You are
> worried that while 'hset' is brief and descriptive, 'hset.stre.wefutr'
> is neither brief, nor descriptive.
> I agree with you - only the person authoring the text that comes after
> hset knows what the name truly means. Should we assume the worst and
> expect people to put in seemingly jumbled text after 'hset'? Or should
> we expect them to put in something meaningful?
I would hope that all future adopters of this Design Pattern /
Microformat will use meaningful descriptions,
but...(there's always a but eh!)
we *are* talking about a potential market of the same mainstream
developers that have a hard time even getting their web-pages to
> Why is being able to specify free form hierarchical identification a bad
> thing? We don't have a problem with people doing it for the 'id'
> attribute. How is this any different? The person viewing the web page
> and the Microformats never sees this data. The computer, which is
> parsing the semantic data, doesn't care if the text following 'hset'
> makes sense or not. Remember, it is okay to give hints to the machine
> At the end of the day, what is important is that a semantic relationship
> has been defined and the solution works for the grouping problem
> description and is compatible with all other Microformats.
> > Ok your example says
> > hset.foo
> > hset.foo.bar
> > hset.foo.baz
> > my example would be
> > <span class="hset">Foo</span>
> > <span class="hset-member">bar</span>
> > <span class="hset-member">baz</span>
> > hset => foo
> > hset-member => bar
> > hset-member => baz
> > does this say the same thing?
> > I know there is more mark up but it does use simple class names that
> > every one can understand
> I agree, it does do the same thing. I'd prefer doing something like what
> you're suggesting. The only problem that would need to be solved is how
> we support sparse grouping with that approach?
We can't, can we?
> > hset.foo.baz
> > looks like a string for a machine, server-side, not client-side
> > ie; in Java
> > System.out.println("abc");
> > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html
> You are exactly right - it is a string for a machine. So are the
> contents of the 'title' attribute in the datetime-abbr-pattern:
> <span class="dtstart" title="20070312T1700-06">
> March 12, 2007 at 5 PM, Central Standard Time
Right now the penny drops Its a compact microformat? or hSet if you
like? as a design pattern it can be used like this
to group dates in a meaningful way, you are also putting the machine
data where it belongs, not in a user space ie
*title here isn't for people but a machine*
<abbr class="dtstart" title="20070312T1700-06">
*title here is for a human*
title="March the 12th, 2007 at 5 PM, Central Standard Time">
12th March 2007 5.00PM (CST)</abbr>
> > but then who am I to judge.
> Somebody that cares about this stuff! Without rigorous vetting of these
> ideas, Microformats would surely fail - so thank you for making sure
> that what we're doing is the right thing to do. The last thing any of us
> want is to cause damage to all the hard work that everybody has done to
> get us this far.
Well Manu after all our discussions on and off the group, I get it
I think hSet will solve many issues when used like this, and above all
it puts machine data where it belongs.
> -- manu
> microformats-new mailing list
> microformats-new at microformats.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2171 bytes
Desc: not available
Url : http://microformats.org/discuss/mail/microformats-new/attachments/20070517/818ce87b/smime.bin
More information about the microformats-new