Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-25 Thread Martin McEvoy 
On Thu, 2007-05-24 at 13:38 -0500, Chris Griego wrote:
 I absolutely agree with Brian's sentiment here that the optional
 container class names that exist today have very different semantics.
 That's why I maintained them in my proposed option[1] while also
 trying to avoid the need for any form of namespacing or notation, dot
 or otherwise, in the class attribute.
 
 Replacing the existing container class names are a non-problem, but I
 recognize that sparse grouping is a problem, which is why I see hSet's
 role more as an alternative to the include-pattern, which is a useful
 solution (that uses the ID attribute) in many situations, but clunky
 at best when dealing with sparse grouping. Case in point is that
 Martin's rev-based option is reinvention of the include-pattern with
 all of the same clunkiness.
 
 [1] 
 http://microformats.org/wiki/grouping-brainstorming#Option_7:_id-class_grouping
 

Chris please explain why rev=has-part is in any way like the include
pattern?, there certainly isn't any clunkiness behind a single
proposed mf that may serve the same purpose as any other more complex
formulas. 

Here are a few references to how I came to my conclusion
http://web.resource.org/rss/1.0/modules/dcterms/#hasPart

http://dublincore.org/groups/collections/collection-application-profile/2007-03-09/#coldctermshasPart

Anyway comments are welcome, have fun ;)

-Martin-



smime.p7s
Description: S/MIME cryptographic signature
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-24 Thread Chris Griego 

I absolutely agree with Brian's sentiment here that the optional
container class names that exist today have very different semantics.
That's why I maintained them in my proposed option[1] while also
trying to avoid the need for any form of namespacing or notation, dot
or otherwise, in the class attribute.

Replacing the existing container class names are a non-problem, but I
recognize that sparse grouping is a problem, which is why I see hSet's
role more as an alternative to the include-pattern, which is a useful
solution (that uses the ID attribute) in many situations, but clunky
at best when dealing with sparse grouping. Case in point is that
Martin's rev-based option is reinvention of the include-pattern with
all of the same clunkiness.

[1] 
http://microformats.org/wiki/grouping-brainstorming#Option_7:_id-class_grouping

--
Chris Griego


On 5/24/07, Brian Suda [EMAIL PROTECTED] wrote:

On 5/23/07, Manu Sporny [EMAIL PROTECTED] wrote:
 Brian Suda wrote:
 We are starting to solve this container problem over and over again.
 We've already created redundant container/grouping/set mechanisms:

--- no they are NOT redundant. They have different semantics.
Microformats are MICRO and they solve a specific problem. If we create
a generic SET object then what does it mean when you begin to have
mixed content in that set? some events, some people, some XYZ format.
This is no longer MICRO but attempts to boil the ocean which is
something we want to avoid.

 Where do we go from here?

 halbum for haudio
 hpodcast for haudio
 hfilm for hvideo
 hmultimedia for haudio and hvideo combinations
 htvseries for hvideo

--- if need be, then yes. hpodcast has very different semantics than
vcalendar. But i am pretty sure that microformats will stay micro, we
are worrying about a problem that does not exist.

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-24 Thread Manu Sporny 
We need more feedback from the community regarding hset. A small poll
has been posted on the various issues surrounding hset. If you can,
please note your preference as to how we handle the hset problem:

1. Please go to the following URL: http://www.advancedsurvey.com/
2. Enter the Survey Number under the Enter Survey # field.
   The number is: 52427

We'll post the results to the list in 2-3 days, or after we get 25-50
completed surveys. This is being done so we can gauge the amount of
interest the community has in solving this problem, and if there is any
preference to how the problem is solved.

-- manu

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-23 Thread Colin Barrett 

On May 22, 2007, at 1:35 PM, Manu Sporny wrote:


using a character that is requires escaping when writing CSS
rules etc.)


Why would we write CSS rules for hset?


For many content authors, one of the main advantages of having data in  
a microformat is to easily style it with CSS. In fact, since the  
classnames and format is standard, you could even have a user style  
sheet in your browser to make hCards appear with a green background  
and a yellow border with a small rolodex card icon too.


If you're seriously asking the question of why would we want to style  
a microformat with CSS, perhaps you're in the wrong place...


-Colin
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-23 Thread Manu Sporny 
Colin Barrett wrote:
 On May 22, 2007, at 1:35 PM, Manu Sporny wrote:
 
 using a character that is requires escaping when writing CSS
 rules etc.)

 Why would we write CSS rules for hset?
 
 For many content authors, one of the main advantages of having data in a
 microformat is to easily style it with CSS. In fact, since the
 classnames and format is standard, you could even have a user style
 sheet in your browser to make hCards appear with a green background and
 a yellow border with a small rolodex card icon too.

I understand why we would want to do this for hCard - I can't understand
why somebody would want to do this for hSet.

Specifically, I don't understand the CSS argument because I haven't seen
enough examples of group highlighting via CSS in the real world.

 If you're seriously asking the question of why would we want to style a
 microformat with CSS, perhaps you're in the wrong place...

The question wasn't that general - Why would we write CSS rules for
hset?. Per the Microformats process - do we have examples of anybody
highlighting that information? I'd be very interested to see some
examples of this as there are none listed in the 68 entries on the
grouping-examples page:

http://microformats.org/wiki/grouping-examples

-- manu

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-23 Thread Martin McEvoy 
On Wed, 2007-05-23 at 14:19 -0400, Manu Sporny wrote:
 Brian Suda wrote:
  On 5/22/07, Manu Sporny [EMAIL PROTECTED] wrote:
  We need a way to create the concept of an audio collection (an album).
  The same can be said for video and images - how do you relate these
  items to one another?
  
  --- i completely agree
 
 Well, at least we agree on that :)
 
  The Problem statement for your grouping is:
  
  It is useful to understand the relationship between objects on a
  website. 
  ...
  that is too generic, OBJECTS on a WEBPAGE? for things like Events, we
  needed a container, so a CALENDAR container was created. For ENTRIES
  we created hFeed. These sort of groupings are handled at the format
  level, not a generalized hSet.
 
 We are starting to solve this container problem over and over again.
 We've already created redundant container/grouping/set mechanisms:
 
 vcalendar for vevents
 hfeed for hentry
 
 Where do we go from here?
 
 halbum for haudio
 hpodcast for haudio
 hfilm for hvideo
 hmultimedia for haudio and hvideo combinations
 htvseries for hvideo
 
 Every single one of these containers does the exact same thing - it
 contains OBJECTS. Why are we calling them different things when they're
 really the same thing. Why are we willing to pollute the Microformats
 namespace with halbum, hpodcast, hfilm, hmultimedia, and htvshow? They
 are just variations on the same theme - grouping.
 
 I understand your position, Brian. In general, Microformat grouping
 should be developed on a case-by-case basis.
 
 However, when it is clear that we are going to have to create multiple
 new Microformat elements that do the /exact same thing/ - we should
 start to question if this problem should not be solved in a more general
 way.
 
  I'm having a hard time understanding what is so complex about:
 
  hset.GROUP_ID.OBJECT_ID
  
  --- to me this makes no sense? in traditional programing languages the
  dot notation is used for member functions which are usually VERBS. The
  Person Object has a function getName(), Person.getName(). 
 
 No, in traditional programming languages, dot notation is used to
 separate package names or object members and methods. It is the de-facto
 method of grouping in most modern programming languages.
 
 C:
 --
 
 void (*operation)();
 struct foo
 {
int bar;
operation do_operation;
 }
 
 foo f;
 f.bar = 5;
 f.do_operation();
 
 C++
 --
 
 class Foo
 {
 public:
int bar;
void doOperation() {};
 }
 
 Foo f = new Foo();
 f.bar = 5;
 f.doOperation();
 
 Python
 ---
 
 class foo:
 def __init__(self):
 self.bar = 0
 
 def do_operation(self):
 pass
 
 f = Foo()
 f.bar = 5
 f.do_operation()
 
 C#
 
 
 public class Foo
 {
public int bar;
 
public void doOperation() {};
 }
 
 f = new Foo()
 f.bar = 5;
 f.doOperation();
 
 Javascript
 
 class Foo
 {
var bar:Integer = 0;
function do_operation() {}
 }
 
 var f = new Foo();
 f.bar = 5;
 f.do_operation()
 
 We would be adopting something that has stood the test of time - we
 wouldn't be re-inventing the wheel.
 
  The
  hset.GROUP_ID.OBJECT_ID tells me nothing not even XML or RDF or
  other mark-up languages use this? everything is done by nesting an
  OBEJCT_ID in a GROUP_ID in an hSet.
 
 It tells you one thing - that if something else has the same GROUP_ID,
 it belongs to the same group. It tells you that there is a relationship
 between two objects.
 
  --- the simplest solution is just to choose a semantic class value for
  your container, we already have 'vcalendar', 'hfeed', which act in
  this capacity. Those are the simplest solutions, lets start there, and
  itterate.
 
 We did start there. Iteration has brought us to the understanding that
 we are going to solve this problem over and over again if we don't do
 something about it. Increasing the number of container elements will
 only pollute the Microformats element space with unnecessary grouping
 mechanisms that do the exact same thing.
 
  We want to make this as easy as possible for publishers, not parsers.
  The vast majority of the people publishing microformats do not have
  PhDs in computer science. We tend to forget that something that seems
  easy for us might be completely over the heads of others.
 
 Using dot notion is not a foreign concept to anybody that has written
 CSS. May I remind you that this is a common practice in CSS:
 
 h1.highlight {
color: yellow;
 }
 
 This will make any h1 element that has a class of 'highlight' to
 appear yellow.
 
 If using dot-notation is such a big problem, we could always use a
 different character, such as '-' or '_'.
 
 hset_foo
 hset_foo_bar
 hset_foo_baz-bat
 
 or
 
 hset-foo
 hset-foo-bar
 hset-foo-baz_bat
 
 or
 
 hset:foo
 hset:foo:bar
 hset:foo:baz-bat
 
 The suggestion to use '.' was made because it is the most common form of
 denoting

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-22 Thread Manu Sporny 
Chris Griego wrote:
 With my proposal for hSet:
 
 h1span id=internal-event class=hset vcalendarInternal/span
 and span id=with-client-event class=hset
 vcalendarWith-Client/span Events/h1
 ol
 li class=with-client-event veventspan class=summaryFOO Sales
 Pitch/span [...]/li
 li class=internal-event veventspan class=summaryCompany
 Picnic/span [...]/li
 li class=with-client-event veventspan class=summaryBAR Photo
 Shoot/span [...]/li
 /ol

Chris,

What you have proposed is definitely a work-able solution. I've added it
as option #7 in the brainstorming section of the page:

http://microformats.org/wiki/grouping-brainstorming#Option_7:_id-class_grouping

There are a few things working against your proposal that I can see (the
option #3 problem solution proposal doesn't have any of these issues):

1. It uses IDs - something Microformats want to avoid.
2. It splits the specification of a set into two parts.
3. It is impossible to define two top-level sets.
4. It mixes identifiers and class names.
5. It is more complex and requires a greater cognitive load on the
   XHTML author.

Here's a bit more detail:

Problem: It uses IDs - something Microformats want to avoid (opinion)
-

I believe you were absolutely correct in your first argument against
using IDs for relationships and grouping. We have avoided using IDs for
Microformats thus far and there is no reason that this Microformat needs
to start using them. The use of classes allow us to define multiple
microformats per XHTML element. We should stay away from using IDs
unless there is no other alternative. Option #3 provides an alternative
to using IDs.

Problem: It splits the specification of a set into two parts


You have split the specification of a set into two parts - the CLASS
part and the ID part. Option #3 does not split the specification into
two parts. This is purely an argument to use a simpler Microformat
option if it exists (which it does: option #3).

Problem: It is impossible to define two top-level sets
--

You cannot define two top-level groups for a single element. For
example, a movie series can be a collection of hImage, hVideo and hAudio
markup as well as being the root element for other sets such as a best
of series. In other words, your solution can only create one set
relationship per XHTML element on the page. Option #3 allows multiple
specifications of set relationships on a per XHTML element basis. It can
do this because it doesn't use ID and instead uses class. Option #3 is
more flexible than your proposal because it allows the creation of
multiple relationships per XHTML element.

Problem: It mixes identifiers and class names (opinion)
---

It mixes two page-level XHTML name spaces that should probably be kept
separate: ID and CLASS. I don't see any reason we should mix these two
name spaces when we don't have to...

Problem: It requires a greater cognitive load on the XHTML author
-

When authoring Microformats, it is hard enough to remember all the
markup. The nice thing is that almost all markup tends to be pretty
localized - when placing semantic hints in the XHTML, you only have to
place them in one location. The problem solution that you have proposed
places the mark-up in two locations. It is also not obvious to anybody
reading the XHTML (yes, people still do this) that the Microformat
described in the class is actually part of a relationship/set/grouping
of some kind.

For these reasons, I believe that Option #3 is still our best bet
because it is the simpler solution. Please debunk as necessary...

-- manu

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-22 Thread Tantek Çelik 
On 5/22/07 9:49 AM, Brian Suda [EMAIL PROTECTED] wrote:

 i'm sorry, i'm completely lost now. Are we trying to get a solution to
 a non-problem? did we not discuss the whole namespacing '.'
 (dot-notation) as a bad idea?
 
 has there ever been a time that we have NEEDED a set container in an
 existing microformat? and any further development of new microformats
 would have container built into them when they are being designed.
 
 i feel this conversation is attempting to create a solution to
 something that isn't a problem.
 
 Can we take a set back from trying to produce mark-up and describe the
 exact use-case and need for this? i for one do NOT see a need for any
 sort of SET format, HTML, XOXO and individual microformats convey all
 the needed semantics already.
 
 -brian

Agreed with all of Brian's points.  I've been quietly watching this thread
hoping for simplification but it doesn't seem to be happening.

Use of . or any other sort of semantic separator in class names is a bad
idea for *numerous* reasons (introducing hierarchy where we there isn't any
currently, using a character that is requires escaping when writing CSS
rules etc.)

I too am convinced that we can do simple sets through aggregation.  Let's
start with that and iterate.

You don't need the all-inclusive format in the first version.  In fact, you
should avoid that.  Start with something *as simple as possible*,  perhaps
even *simpler* than you think possible.  Classes with hierarchy and special
characters (not to mention hiding data in the class attribute) are so far
beyond simple it is ridiculous.

Thanks,

Tantek

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-21 Thread Martin McEvoy 
Hello Chris, thanks for your proposal

On Sat, 2007-05-19 at 14:50 -0500, Chris Griego wrote:
 Thanks Manu.
 
 I think the purpose of hSet can be achieved with a much simpler
 approach, nearly simplifying the entire schema of the format to just
 the 'hset' class name by leveraging conventions. I think my suggestion
 lies somewhere between the existing Option #3 and #4. Since I haven't
 kept up all that well with the hAudio progress, forgive me while I use
 hCalendar as an example. Say you have a chronological list of events
 that you want to relate with one of two calendars, making the
 individual calendars a sparse grouping.
 
 Before microformats:
 
 h1Internal and With-Client Events/h1
 ol
  liFOO Sales Pitch [...]/li
  liCompany Picnic [...]/li
  liBAR Photo Shoot [...]/li
 /ol
 
 With microformats (today this would be parsed as a 3 calendars, 2
 without any events):
 
 h1span class=vcalendarInternal/span and span
 class=vcalendarWith-Client/span Events/h1
 ol
  li class=veventspan class=summaryFOO Sales Pitch/span [...]/li
  li class=veventspan class=summaryCompany Picnic/span [...]/li
  li class=veventspan class=summaryBAR Photo Shoot/span [...]/li
 /ol
 
 With my proposal for hSet:
 
 h1span id=internal-event class=hset vcalendarInternal/span
 and span id=with-client-event class=hset
 vcalendarWith-Client/span Events/h1
 ol
  li class=with-client-event veventspan class=summaryFOO Sales
 Pitch/span [...]/li
  li class=internal-event veventspan class=summaryCompany
 Picnic/span [...]/li
  li class=with-client-event veventspan class=summaryBAR Photo
 Shoot/span [...]/li
 /ol
 
 Using the hset class names attaches special meaning to the element's
 ID value, marking it as the machine-readable group name, and then any
 other element in the document with a class name that matches the ID
 should be considered a set member. The class attribute is a natural
 grouping mechanism, by simply marking contacts across the internet
 with 'vcard' we've grouped them in the category of contact
 information.
 
 I know that earlier in this discussion I've warned against using the
 ID attribute since microformats should be low-impact for
 implementation into existing content; but I feel this usage still
 holds true to that principle since it can work well with existing IDs.
 IDs are currently used as a part of the include-pattern, and I see
 hSet's role as an alternative (not replacement) to the include-pattern
 that reverses the declaration where the children declare their parent
 instead of the parent declaring its children.
 

To give you some pointers, what we are trying to do, is cram all the
information needed about our grouping into one class, the key reasons
for this are:

* Groups and Members can be associated with one another without needing
to be hierarchically grouped, network relationships are often not
hierarchical
* The structure of the page should not affect grouping.

http://microformats.org/wiki/grouping-brainstorming#Purpose

To use your example if I syndicated, shared, downloaded one of your
events, I would not know If this was a collection item or not

class=with-client-event vevent

I know that this is with a client but what am I doing? and Is this part
of a group? I will only understand its true meaning when its grouped on
a page.

The current hset proposal would say

class=hset with-client-event.FOO_Sales_Pitch

the whole class declares that its a grouping, a client event and its
sales pitch about foo, 
* it doesn't need to be hierarchically grouped or even on the same page
* its easy to markup no id issues.
* It can be sparsely grouped 

why do I feel your proposal has issues?
It relies on the child to be grouped together with the parent for it to
have any meaning. 
If you had Many ID's on a single page all attaching their special
meaning, do you think this may cause some problems for browsers or
phraser? 

I know that Both Manu and I would both like a proposal like yours, but
truthfully it doesn't quite fit our problem.

-Martin McEvoy-
 


smime.p7s
Description: S/MIME cryptographic signature
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-19 Thread Chris Griego 

Before you start on a full-blown proposal, can you create a sample
page? I know that personally I'm having trouble mentally translating
your pseudo markup into what the HTML markup would actually look like.
I think I have some ideas on how this could work more simply as a
convention, but without seeing what you're trying to achieve I don't
know if it answers the problem or not.

--
Chris Griego


On 5/18/07, Manu Sporny [EMAIL PROTECTED] wrote:

Martin McEvoy wrote:
 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?

We've been wracking our collective brains on how to make what your
proposed to work, but keep having the same sorts of problems. If we
didn't have to deal with sparse groups, your solution would be perfect.

In a way, this is a perfect example of why we need to collect examples
for any Microformat - if we weren't collecting examples, we would have
probably adopted something very similar to what you proposed (and not
addressing the real problem in the end).

 Right now the penny drops Its a compact microformat? or hSet if you
 like? as a design pattern it can be used like this

 hset.dtstart.20070312T1700-06

I don't think we should expand it to a design pattern until we see it
used in several other Microformats. Let's keep it semi-constrained for
right now because it doesn't cost us anything to do so.

In addition, several Microformats will need to use hset to identify it
as a design pattern. You are correct - it is a VERY simple Microformat
and probably will become a design pattern eventually.

Let's let hset take its natural course and not rush it into being a
design pattern before we are sure it will be used as such.

 I think hSet will solve many issues when used like this, and above all
 it puts machine data where it belongs.

Then if there are no objections - I'll write up an hset proposal and
submit it to the list for feedback in the next week or two. We'll do one
more round of feedback for haudio and hset after that and see where we
stand.

-- manu
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new


___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-19 Thread Manu Sporny 
Chris Griego wrote:
 Before you start on a full-blown proposal, can you create a sample
 page?

Martin McEvoy already has one set up based on a real-world example:

http://weborganics.co.uk/haudio

There is also the brainstorming page, look at Option #3:

http://microformats.org/wiki/grouping-brainstorming#Option_3:_Explicit_class-based_grouping

The only difference is the change from grouping to hset.

 I think I have some ideas on how this could work more simply as a
 convention, but without seeing what you're trying to achieve I don't
 know if it answers the problem or not.

You should also look through the grouping-examples page to get an idea
of the problem that we are attempting to solve:

http://microformats.org/wiki/grouping-examples

If you've got some other problem solution proposals, we'd love to hear them.

-- manu


___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-19 Thread Chris Griego 

Thanks Manu.

I think the purpose of hSet can be achieved with a much simpler
approach, nearly simplifying the entire schema of the format to just
the 'hset' class name by leveraging conventions. I think my suggestion
lies somewhere between the existing Option #3 and #4. Since I haven't
kept up all that well with the hAudio progress, forgive me while I use
hCalendar as an example. Say you have a chronological list of events
that you want to relate with one of two calendars, making the
individual calendars a sparse grouping.

Before microformats:

h1Internal and With-Client Events/h1
ol
liFOO Sales Pitch [...]/li
liCompany Picnic [...]/li
liBAR Photo Shoot [...]/li
/ol

With microformats (today this would be parsed as a 3 calendars, 2
without any events):

h1span class=vcalendarInternal/span and span
class=vcalendarWith-Client/span Events/h1
ol
li class=veventspan class=summaryFOO Sales Pitch/span [...]/li
li class=veventspan class=summaryCompany Picnic/span [...]/li
li class=veventspan class=summaryBAR Photo Shoot/span [...]/li
/ol

With my proposal for hSet:

h1span id=internal-event class=hset vcalendarInternal/span
and span id=with-client-event class=hset
vcalendarWith-Client/span Events/h1
ol
li class=with-client-event veventspan class=summaryFOO Sales
Pitch/span [...]/li
li class=internal-event veventspan class=summaryCompany
Picnic/span [...]/li
li class=with-client-event veventspan class=summaryBAR Photo
Shoot/span [...]/li
/ol

Using the hset class names attaches special meaning to the element's
ID value, marking it as the machine-readable group name, and then any
other element in the document with a class name that matches the ID
should be considered a set member. The class attribute is a natural
grouping mechanism, by simply marking contacts across the internet
with 'vcard' we've grouped them in the category of contact
information.

I know that earlier in this discussion I've warned against using the
ID attribute since microformats should be low-impact for
implementation into existing content; but I feel this usage still
holds true to that principle since it can work well with existing IDs.
IDs are currently used as a part of the include-pattern, and I see
hSet's role as an alternative (not replacement) to the include-pattern
that reverses the declaration where the children declare their parent
instead of the parent declaring its children.

--
Chris Griego


On 5/19/07, Manu Sporny [EMAIL PROTECTED] wrote:

Chris Griego wrote:
 Before you start on a full-blown proposal, can you create a sample
 page?

Martin McEvoy already has one set up based on a real-world example:

http://weborganics.co.uk/haudio

There is also the brainstorming page, look at Option #3:

http://microformats.org/wiki/grouping-brainstorming#Option_3:_Explicit_class-based_grouping

The only difference is the change from grouping to hset.

 I think I have some ideas on how this could work more simply as a
 convention, but without seeing what you're trying to achieve I don't
 know if it answers the problem or not.

You should also look through the grouping-examples page to get an idea
of the problem that we are attempting to solve:

http://microformats.org/wiki/grouping-examples

If you've got some other problem solution proposals, we'd love to hear them.

-- manu


___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new


___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-18 Thread Manu Sporny 
Martin McEvoy wrote:
 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?

We've been wracking our collective brains on how to make what your
proposed to work, but keep having the same sorts of problems. If we
didn't have to deal with sparse groups, your solution would be perfect.

In a way, this is a perfect example of why we need to collect examples
for any Microformat - if we weren't collecting examples, we would have
probably adopted something very similar to what you proposed (and not
addressing the real problem in the end).

 Right now the penny drops Its a compact microformat? or hSet if you
 like? as a design pattern it can be used like this
 
 hset.dtstart.20070312T1700-06 

I don't think we should expand it to a design pattern until we see it
used in several other Microformats. Let's keep it semi-constrained for
right now because it doesn't cost us anything to do so.

In addition, several Microformats will need to use hset to identify it
as a design pattern. You are correct - it is a VERY simple Microformat
and probably will become a design pattern eventually.

Let's let hset take its natural course and not rush it into being a
design pattern before we are sure it will be used as such.

 I think hSet will solve many issues when used like this, and above all
 it puts machine data where it belongs.

Then if there are no objections - I'll write up an hset proposal and
submit it to the list for feedback in the next week or two. We'll do one
more round of feedback for haudio and hset after that and see where we
stand.

-- manu
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-17 Thread Manu Sporny 
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?

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
(abbr-design-pattern).

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=hsetFoo/span
 span class=hset-memberbar/span
 span class=hset-memberbaz/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?

 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
/span

 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.

-- manu
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-17 Thread Martin McEvoy 
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
Validate right?

 
 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
 (abbr-design-pattern).
 
 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=hsetFoo/span
  span class=hset-memberbar/span
  span class=hset-memberbaz/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
 /span

Right now the penny drops Its a compact microformat? or hSet if you
like? as a design pattern it can be used like this

hset.dtstart.20070312T1700-06 

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*
abbr class=hset.dtstart.20070312T1700-06 
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
now ;)

I think hSet will solve many issues when used like this, and above all
it puts machine data where it belongs.
...

Martin
 
 -- manu
 ___
 microformats-new mailing list
 microformats-new@microformats.org
 http://microformats.org/mailman/listinfo/microformats-new


smime.p7s
Description: S/MIME cryptographic signature
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-16 Thread Manu Sporny 
Martin, to start off - thanks for updating your hAudio examples page...
even though you have issues with the proposal. Personally, I feel that
the XHTML is much cleaner now and accomplishes all of the goals listed
in the grouping-examples page. However, it would be foolish to press
ahead if there are still very strong opinions against grouping in
Microformats, or option #3.

Martin McEvoy wrote:
 Sounds trivial but I have to ask, if the method you have proposed is
 just for identification then why use . as a separator when you know
 what you intend will meet disapproval from many users and developers

I don't fully understand the point you are making. You have mentioned
your aversion to using '.' as a separator. What separator should we use?
 Or is it the fact that we are using a separator that bothers you?
Please be more specific.

You have also asserted several things that I'm having a hard time
understanding:

 Microformats, particularly when one of the first things you will ever
 read about mF is...
 
 simple conventions for embedding semantic markup

What is not a simple convention for embedding semantic markup about
option #3? Are you worried about complexities that might arise out of
mixing this markup with other forms of markup? If so, what complexities
do you see?

 using brief, descriptive class names

hset is a brief descriptive class name, isn't it?

 namespaces for content are considered harmful
 
 and 
 
 If you want to carry on a theoretical discussion of namespaces, please
 do so elsewhere, for in practice, discussing them is a waste of time,
 and off-topic for microformats lists.

We are not talking about name space markup. We are talking about object
identification. I think you are mis-understanding what that page is
talking about.

Name space markup is this:

mynamespace
   problem_statementThe problem with namespaces, is that everybody can
invent their own namespace.
   /problem_statement
   problem_explanationThis is not a problem when dealing with a local
name space, such as variables inside a function in a functional
programming language. However, inventing your own namespace becomes a
problem when you want your data to interoperate with somebody elses
data. The name spaces must be mapped to one another and in most cases
this is very difficult.
   /problem_explanation
   problem_solutionMicroformats steer clear of name spaces for a very
good reason. Microformats are a universal markup mechanism and thus
cannot have anybody inventing tags/elements when they feel like it.
However, this is not to be confused with the way we identify information
in Microformats.
   /problem_solution
/mynamespace

Object Identification markup is this:

hset.object_id

Object identification as it relates to hSet is always local to the page.
It doesn't matter what the identification string is, all of these are
equivalent groups:

hset.a
hset.a.b
hset.a.3

hset.1
hset.1.2
hset.1.c

hset.foo
hset.foo.bar
hset.foo.baz

To humans and to a parser, the relationship graph mentioned above is the
exact same thing. We are only talking about IDs and relationships
between the IDs. This is not true if we were talking about a name space:

a
 b/b
 3/3
/a

1
 2/2
 c/c
/1

foo
 bar/bar
 baz/baz
/foo

The name spaces and thus the structure of the documents listed above are
definitely not the same.

Don't confuse name spaces with the grouping problem - they are very
different from each other.

 I don't think grouping is an issue for hAudio, or hVideo and hImage, as
 I believe this feature firmly belongs with hMedia the container or
 transport for any media related mF's

You are correct. Grouping isn't an issue for hAudio. Grouping is an
issue for hSet.

It just so happens that hAudio needs hSet to express relationships that
are needed by hAudio (such as album/track and podcast/clip). With the
current proposal, we won't need an hMedia container format. One less
Microformat is good. Plus, hSet will be applicable to any other grouping
discussion.

 I believe hAudio and any descendants should more resemble a vCard that
 can be sprinkled in to hMedia or any other mF's for that matter.

It currently does, and it will. hSet will not affect hAudio's ability to
be mixed into other Microformats. I don't know if I'm missing something
obvious here... please let us know if there is a reason that using hSet
would not allow us to use hAudio in the same way hCard is used.

-- manu
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-16 Thread Martin McEvoy 
On Wed, 2007-05-16 at 14:00 -0400, Manu Sporny wrote:
 Martin, to start off - thanks for updating your hAudio examples page...
 even though you have issues with the proposal. Personally, I feel that
 the XHTML is much cleaner now and accomplishes all of the goals listed
 in the grouping-examples page. However, it would be foolish to press
 ahead if there are still very strong opinions against grouping in
 Microformats, or option #3.

I agree Manu it does look cleaner.

 
 Martin McEvoy wrote:
  Sounds trivial but I have to ask, if the method you have proposed is
  just for identification then why use . as a separator when you know
  what you intend will meet disapproval from many users and developers
 
 I don't fully understand the point you are making. You have mentioned
 your aversion to using '.' as a separator. What separator should we use?
  Or is it the fact that we are using a separator that bothers you?
 Please be more specific.
 
 You have also asserted several things that I'm having a hard time
 understanding:
 
  Microformats, particularly when one of the first things you will ever
  read about mF is...
  
  simple conventions for embedding semantic markup
 
 What is not a simple convention for embedding semantic markup about
 option #3? Are you worried about complexities that might arise out of
 mixing this markup with other forms of markup? If so, what complexities
 do you see?
 
  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.

 
  namespaces for content are considered harmful
  
  and 
  
  If you want to carry on a theoretical discussion of namespaces, please
  do so elsewhere, for in practice, discussing them is a waste of time,
  and off-topic for microformats lists.
 
 We are not talking about name space markup. We are talking about object
 identification. I think you are mis-understanding what that page is
 talking about.
 
 Name space markup is this:
 
 mynamespace
problem_statementThe problem with namespaces, is that everybody can
 invent their own namespace.
/problem_statement
problem_explanationThis is not a problem when dealing with a local
 name space, such as variables inside a function in a functional
 programming language. However, inventing your own namespace becomes a
 problem when you want your data to interoperate with somebody elses
 data. The name spaces must be mapped to one another and in most cases
 this is very difficult.
/problem_explanation
problem_solutionMicroformats steer clear of name spaces for a very
 good reason. Microformats are a universal markup mechanism and thus
 cannot have anybody inventing tags/elements when they feel like it.
 However, this is not to be confused with the way we identify information
 in Microformats.
/problem_solution
 /mynamespace

I understand this.

 
 Object Identification markup is this:
 
 hset.object_id
 
 Object identification as it relates to hSet is always local to the page.
 It doesn't matter what the identification string is, all of these are
 equivalent groups:
 
 hset.a
 hset.a.b
 hset.a.3
 
 hset.1
 hset.1.2
 hset.1.c
 
 hset.foo
 hset.foo.bar
 hset.foo.baz
 
 To humans and to a parser, the relationship graph mentioned above is the
 exact same thing. We are only talking about IDs and relationships
 between the IDs. This is not true if we were talking about a name space:
 
 a
  b/b
  3/3
 /a
 
 1
  2/2
  c/c
 /1
 
 foo
  bar/bar
  baz/baz
 /foo
 
 The name spaces and thus the structure of the documents listed above are
 definitely not the same.
 
 Don't confuse name spaces with the grouping problem - they are very
 different from each other.

Ok your example says

hset.foo
hset.foo.bar
hset.foo.baz

my example would be 

span class=hsetFoo/span
span class=hset-memberbar/span
span class=hset-memberbaz/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 don't think grouping is an issue for hAudio, or hVideo and hImage, as
  I believe this feature firmly belongs with hMedia the container or
  transport for any media related mF's
 
 You are correct. Grouping isn't an issue for hAudio. Grouping is an
 issue for hSet.
 
 It just so happens that hAudio needs hSet to express relationships that
 are needed by hAudio (such as album/track and podcast/clip). With the
 current proposal, we won't need an hMedia container format. One less
 Microformat is good. Plus, hSet will be applicable to any other grouping
 discussion.
 
  I believe hAudio and any

Re: [uf-new] Revisiting grouping problem solution proposal: hset

2007-05-15 Thread Martin McEvoy 
On Tue, 2007-05-15 at 00:57 -0400, Manu Sporny wrote:
 After collecting even more grouping examples and performing analysis on
 those examples, it is quite evident that we need to support ordered,
 unordered, sparse and non-sparse grouping. There are several options
 that have been gathered over the past month, listed on the
 grouping-brainstorming page:
 
 http://microformats.org/wiki/grouping-brainstorming
 
 Option #3 seems to have the least number of things working against it.
 The major argument has been made against Option #3 is that it is a
 namespace approach to ordering. Some have cited the following page for
 reference:
 
 http://microformats.org/wiki/namespaces
 
 After pouring over the links on the namespaces page, it seems to be an
 invalid argument. Namespaces deal with global data markup. Grouping
 option #3 (and variants) deal with local identification and grouping.
 These are two completely separate solutions to two completely separate
 problems.
 
 Namespacing is a problem because it requires that all entities marking
 up data agree on a GLOBAL name space and element names. The proposal put
 forth in option #3 does not require that any entities agree on a global
 name space. Element names do not need to be agreed upon either. Option
 #3 is purely an identification mechanism.
 
 I am retracting my support for Option #5 and suggesting that we go with
 Option #3:
 
 http://microformats.org/wiki/grouping-brainstorming#Option_3:_Explicit_class-based_grouping
 
 Martin, the hAudio test page that you have up is great. Could we try
 looking at it using Option #3 as the group markup example? After using
 the method that you currently have active on your page, I can't help but
 feel that it isn't quite what we want. There is a reason you had to add
 CSS to make the tabbing work correctly - you were using XHTML markup
 methods that shouldn't be used to imply grouping.

Sounds trivial but I have to ask, if the method you have proposed is
just for identification then why use . as a separator when you know
what you intend will meet disapproval from many users and developers of
Microformats, particularly when one of the first things you will ever
read about mF is...

simple conventions for embedding semantic markup

and

using brief, descriptive class names

http://microformats.org/wiki/Main_Page#Definition

hSet does not fit into any of these...

Later you may read...

namespaces for content are considered harmful

and 

If you want to carry on a theoretical discussion of namespaces, please
do so elsewhere, for in practice, discussing them is a waste of time,
and off-topic for microformats lists.

http://microformats.org/wiki/namespaces


I don't think grouping is an issue for hAudio, or hVideo and hImage, as
I believe this feature firmly belongs with hMedia the container or
transport for any media related mF's

I believe hAudio and any descendants should more resemble a vCard that
can be sprinkled in to hMedia or any other mF's for that matter.

Anyway having said all that I have relented why not, as no one manged to
come up with a suitable alternative to work with, so lets suck it and
see

The hAudio test page has been updated with all your proposals.

http://weborganics.co.uk/haudio


-- Martin.

 
 So, will this work for grouping:
 
 - Groups/Collections are identified with the following: hset
 - Hierarchial ordering is performed by doing: hset.NAME
 - Ordered grouping is performed by using xoxo
 
 Here is an example:
 
 hvideo hset.kbv1
   hvideo.title = Kill Bill Volume 1
   hvideo.collaborator = Quentin Tarantino (role=writer) [hCard]
   hvideo.collaborator = Uma Thurman (role=writer,role=actress) [hCard]
   hvideo.collaborator = Lawrence Bender   (role=producer) [hCard]
   ...
   haudio hset.kbv1.i_walk_like_jayne_mansfield
  haudio.title = I Walk Like Jayne Mansfield
  haudio.collaborator = The 5.6.7.8's (role=band) [hCard]
   haudio hset.kbv1.im_blue
  haudio.title = I'm Blue
  haudio.collaborator = The 5.6.7.8's (role=band) [hCard]
   haudio hset.kbv1.woo_hoo
  haudio.title = Woo Hoo
  haudio.collaborator = The 5.6.7.8's (role=band) [hCard]
   ...
   himage hset.kbv1.cover_image
  himage.title = Kill Bill Volume 1 DVD Cover Image (UK Release)
 
 -- manu
 
 ___
 microformats-new mailing list
 microformats-new@microformats.org
 http://microformats.org/mailman/listinfo/microformats-new


smime.p7s
Description: S/MIME cryptographic signature
___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new

[uf-new] Revisiting grouping problem solution proposal: hset

2007-05-14 Thread Manu Sporny 
After collecting even more grouping examples and performing analysis on
those examples, it is quite evident that we need to support ordered,
unordered, sparse and non-sparse grouping. There are several options
that have been gathered over the past month, listed on the
grouping-brainstorming page:

http://microformats.org/wiki/grouping-brainstorming

Option #3 seems to have the least number of things working against it.
The major argument has been made against Option #3 is that it is a
namespace approach to ordering. Some have cited the following page for
reference:

http://microformats.org/wiki/namespaces

After pouring over the links on the namespaces page, it seems to be an
invalid argument. Namespaces deal with global data markup. Grouping
option #3 (and variants) deal with local identification and grouping.
These are two completely separate solutions to two completely separate
problems.

Namespacing is a problem because it requires that all entities marking
up data agree on a GLOBAL name space and element names. The proposal put
forth in option #3 does not require that any entities agree on a global
name space. Element names do not need to be agreed upon either. Option
#3 is purely an identification mechanism.

I am retracting my support for Option #5 and suggesting that we go with
Option #3:

http://microformats.org/wiki/grouping-brainstorming#Option_3:_Explicit_class-based_grouping

Martin, the hAudio test page that you have up is great. Could we try
looking at it using Option #3 as the group markup example? After using
the method that you currently have active on your page, I can't help but
feel that it isn't quite what we want. There is a reason you had to add
CSS to make the tabbing work correctly - you were using XHTML markup
methods that shouldn't be used to imply grouping.

So, will this work for grouping:

- Groups/Collections are identified with the following: hset
- Hierarchial ordering is performed by doing: hset.NAME
- Ordered grouping is performed by using xoxo

Here is an example:

hvideo hset.kbv1
  hvideo.title = Kill Bill Volume 1
  hvideo.collaborator = Quentin Tarantino (role=writer) [hCard]
  hvideo.collaborator = Uma Thurman (role=writer,role=actress) [hCard]
  hvideo.collaborator = Lawrence Bender (role=producer) [hCard]
  ...
  haudio hset.kbv1.i_walk_like_jayne_mansfield
 haudio.title = I Walk Like Jayne Mansfield
 haudio.collaborator = The 5.6.7.8's (role=band) [hCard]
  haudio hset.kbv1.im_blue
 haudio.title = I'm Blue
 haudio.collaborator = The 5.6.7.8's (role=band) [hCard]
  haudio hset.kbv1.woo_hoo
 haudio.title = Woo Hoo
 haudio.collaborator = The 5.6.7.8's (role=band) [hCard]
  ...
  himage hset.kbv1.cover_image
 himage.title = Kill Bill Volume 1 DVD Cover Image (UK Release)

-- manu

___
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new