- From: Elias Torres <elias@torrez.us>
- Date: Thu, 07 Dec 2006 01:15:09 -0500
Thanks for your patience trying to work out these extremely hypothetical examples with me. I need to figure out a way to get the internal examples out here so we can discuss them concretely. In the meantime, you have motivated me to look at the existing infrastructure with a different perspective and try to see how we can solve our problems without adding new attributes. One of the key problems I'm trying to solve is to have a single parser for all HTML files. I'll keep the list posted on my progress on that and come back when I have more information on the rest. Thanks. -Elias Ian Hickson wrote: > On Tue, 5 Dec 2006, Elias Torres wrote: >>>> <div> <span class="ibm-part-description">our part number <span >>>> class="part-id">123</span></span></div> >>> Yes? What about it? >> I guess this is similar to Karl's example. >> >> <div id="order1" class="ibm-order"> >> <span class="ibm-part-description">our part number >> <span class="part-id">123</span> >> </span> >> </div> >> >> part-id would according to microformats be a property of >> ibm-part-description existential instead of order1. Is there way to >> specify that kind of behavior. Would include do the trick here? > > I don't understand what you mean by "existential" in this paragraph. > > If you are saying "how do we make the pard-id be a property of the order > instead of the description", then the answer is: > > <div id="order1" class="ibm-order"> > <span class="ibm-part-description">our part number</span> > <span class="part-id">123</span> > </div> > > >>>> Microformats is very restrictive in how you can parse the data. >>> I don't understand why you think this. Could you elaborate? >> I guess restrictive is the wrong word, it's only defined to say you must >> grab the entire HTML content within the element. Fair enough again. >> Although, I'd like to differentiate between HTML sub-content, plain text >> and also specify which data type. quantity is an integer/long/etc. > > Well, you can define your structure pretty much as you like, nothing > forces you to define "description" in the example above as being the > entire contents, you could just as easily say that your processing model > only involves the direct child text nodes, or some such. > > >>>> We need the flexibility of specify the content everywhere, yet the >>>> property apply to any element on the page, not just the parent >>>> element. >>> Again, concrete examples would really help me understand this? >> In some part of the page.... >> >> <div id="picture1"> >> <img src="picture1.jpg"> >> </div> >> >> Now somewhere else in the page.... >> >> <div> >> <span about="picture1" property="dc:title">A Night in Venice</span> >> <div> >> >> Here I'm able to connect two elements in the page. I'm not sure how I >> would use id to differentiate the two. > > Why would you need this? Just have: > > <figure> > <img src="picture1.jpg" alt=""> > <legend> A night in Venice </legend> > </figure> > > If you could provide a URI to a document showing why you need the legend > and the figure split from each other, that would be very useful. > > > I can't emphasise enough that it would really help if you could point to > some real world examples (with URIs) showing what we are talking about. > Currently, as I've mentioned before, it feels very hypothetical. > > > On Tue, 5 Dec 2006, Elias Torres wrote: >> I think we keep focusing on the ways to extract information and I don't >> disagree that we could find a million ways to hack class attributes to >> do so. I can see myself doing class="about-subjectName", >> class="predicate-propertyName", and so on. If anything, what I'm asking >> for is a less hacky way of using "ibm-xxxxx" for everything and maybe >> have a way to denote a prefix and a property attribute to different >> properties from classes. Let me know if this would bring down HTML5 if >> we were to try. > > I really don't follow. Why do you need prefixes? What is "hacky" about the > well-defined and accessible extension model in HTML today? > > >> On the other hand, we keep missing the point, that no matter what the >> syntax is, in microformats at least (our current answer) we can't >> differentiate from class values that are properties/classes(types) and >> which ones are not. > > You know which are which. You invented them. (Although, what's a class > value that _isn't_ a "property/class(type)" ?) > > >> In our scenarios that we have been exchanging is nothing but ideal to >> see how the structure maps to our data and how easy is to write JS to >> get at it. However, we are looking for a mechanism that focuses on >> property attribute to know when someone indicated a property as opposed >> to just a style. > > Don't use class for styles. Problem solved. > > >> It's like imagining a generic microformat extractor that generates JSON >> objects on any random webpage with a lot of different styles and a few >> hCards here and there. Is this really ideal? I think that before HTML5 >> microformats did what it could with what is there (not to say that HTML >> isn't semantic at all today), but if we can define more clearly defined >> attributes to do so, why not? > > Could you show me Web pages that are trying to do what you are referring > to, which would benefit from what you are describing? It would really help > me understand what problem you are trying to solve. > > >> Do you see any workable solution? > > To be honest I don't understand the problem, let alone have a solution. >
Received on Wednesday, 6 December 2006 22:15:09 UTC