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_statement>The problem with namespaces, is that everybody can
> invent their own namespace.
> </problem_statement>
> <problem_explanation>This 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_solution>Microformats 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="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 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.
Sorry again Manu there is no reason why we cant use haudio in the same
way as a vcard.
I am a little set in my ways, and For all I know I could be wrong in my
logic, I am just trying to make it clear on what you are trying to do
and more importantly why? I cant help thinking that
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
but then who am I to judge.
--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
