On 10/27/05, James M Snell <[EMAIL PROTECTED]> wrote:
>
> Luke Arno wrote:
>
> >*Some* of those benefits would apply to any existing
> >XML format such as OPML to varying degrees.
> >
> >1. Visible data.
> >
> >More clients understand (X)HTML than any other format.
> >
> >
> >
> Clients for whom APP support is important will adopt to whatever format
> we choose. The data is no less visible to clients if it is formatted
> using a Non-XHTML based XML format than if it was served with XHTML.
> More clients understand RSS than Atom, does that mean that RSS data is
> more visible than Atom data? Hardly.
>
Wow. Your definition of data visibility is not mine.
Data visibility: The degree to which data is seen by people.
A lot of people have these cool programs called web browsers.
> >2. Principle of least invention.
> >
> >(X)HTML is the lingua franka of the web.
> >
> >
> >
> Agreed. This is why I have pointed out that format reuse is a very
> strong consideration that is worth our attention.
>
> >3. Layered semantics.
> >
> >XHTML has a built in facility for layered semantics
> >through class, id, rel and other attributes.
> >
> >Rob's document, if he converted it to use my profile,
> >could be seen as XML, XHTML, XOXO, and APP
> >introspection all at once. Many parsers could use
> >it and many systems could find meaning in it
> >(including human beings).
> >
> >
> >
> Layered semantics can be built into any XML format we either adopt or
> design. the point that it's already in XHTML is well taken but the
> question still remains about whether or not it is important for us to be
> able to view an introspection document in multiple ways.
>
Data that is understandable in more ways by more
systems yields more value.
We *can* do it in other formats but in XHTML it will
actually be done.
> >4. Maintain fewer documents.
> >
> >Would you use OPML to publish your blog or would
> >you also have to maintain an XHTML version
> >(or an XSLT to produce it or whatever)?
> >
> >
> >
> Blog data is already being published in multiple formats. You are
> making a valid argument here, but I'm still not yet convinced that it is
> enough to justify using XHTML in this case.
>
You are going to throw out your elbow.
Again with this "enough" thing... weighed against what?
"Enough" is undefined until you define costs to compare
your benefits to.
> >5. Learn less new syntax.
> >
> >Again XHTML is the lingua franka. I would have to
> >use references to work with OPML. It is simple but
> >I don't use it every day. I can sit down and write
> >XHTML from memory.
> >
> >
> >
> This is another valid argument in favor of reuse, but are you assuming
> that everyone is able to write valid, modularized XHTML from memory?
> Look at the example with the img and br tags from yesterday. I'm
> certain that Robert is *very* knowledgeable about XHTML and XOXO and yet
> he was incorrect about whether or not br tags in XOXO were valid. I'm
> not arguing against XHTML here, I'm just questioning an assumption you
> appear to be making that writing valid XHTML is somehow easier than
> writing valid instances of other XML syntaxes.
>
The number of people with one skill set vs. the other
must be staggering. Are you trying to tell me that more
people know OPML than XHTML?
> >6. Fewest possible constraints.
> >
> >XHTML is a very flexible and if our profile just
> >sprinkles on the extra semantics we need then
> >the possibilities are endless *without resorting to
> >namespace etc.* This is a shortcoming of using
> >XOXO. Notice how in order to add seek, Rob had
> >to throw in a namespaced attribute, and is
> >not just using XHTML anymore. By using our own
> >profile, we allow further extension to be done in
> >the same way: using XHTML.
> >
> >
> >
> The fewer the constraints, the harder it is to validate given that
> anything can be considered valid.
False! Each constraint is another check.
> The benchmark should be "the fewest
> possible constraints relative to the requirements of the protocol" lest
> we build in so much flexibility that the protocol ceases to be useful
> due to lack of enforceability.
I thought this was implied but I will say it.
Fewest possible constraints in order to achieve
desired functionality.
Enforcable interop is something we do not disagree on.
> A case in point is the mime type
> dispatching issue. If an mime type used for an introspection document
> is optional, we'll end up with several different, non-standardized ways
> of dispatching. FWIW, RSS has a similar problem with its content model:
> e.g., do you use description, do you use content:encoded, do you use
> xhtml:div, or do you use some other mechanism, .... or do you use any of
> the above? The answer is always yes which has caused many many
> implementation headaches for a lot of people.
>
This is completely different. With RSS you don't know what to
do when. We have three clear cases.
1. Browser views document - text/html
2. Browser follow link to dispatch - application/[APP]
3. Client requests document itself - either one
> Your proposal says,
>
> The title of an APP collection will be the title of the
> XHTML anchor or link with rel='entry' or 'generic' pointing
> to the collection's primary feed.
> If these are not present then it will be the text of the
> anchor (if it is an anchor).
> If these are not present then the contents of the
> element within the collection (but not within a nested
> collection) with a class name of collectionTitle
> will be considered the name of the collection.
> If none of these exist, it is highest ranking heading element
> within the collection container.
> If none of these exist, it is simply an unnamed collection.
>
> Does that mean that if the contents the anchor (or collectionTitle, etc)
> contains additional markup (e.g br tags) that markup is part of the
> title of the collection?
>
"Contents" means what you would get from an xsl:value-of:
concatenation of text node descendants.
Obviously that would have to be written somewhere in a
way that references the appropriate spec (XPath I think)
This profile is being changed and simplified a lot BTW.
The version you are looking at still kinda sucks.
> The reason I ask is to illustrate the point that in order for XHTML to
> be useful to us, we HAVE to add constraints. Not only that, we have to
> be smart enough to identify all of the really important constraints that
> need to be added or else we run the risk of having to go back and
> retrofit additional constraints -- a process that is notoriously difficult.
>
This is all true stuff about spec writing.
> Starting with a new syntax affords us the opportunity to design to a
> specific set of known requirements and constraints without needing to
> retrofit anything. If we're smart and build extensibility into the
> model, then the syntax can be evolved as needs evolve.
>
Classic tower of babel. It is just lazy. Yet another DTD
because it is easier to talk to ourselves than
communicate in a way that others understand.
> Example : your approach requires me to look in four different places for
> a collection title and does not indicate whether markup is allowed in
> the title and takes five sentences to explain. The existing workspace
> stuff defines a single location for title and is explained much more
> concisely, "The app:workspace element MUST contain a 'title' attribute,
> which conveys a human-readable name for the workspace. This attribute is
> Language-Sensitive." Which is easier to learn/implement/validate?
>
This is valid feedback and my first attempts at this
profile are way too complicated. I went all the way
with flexibility and it was an over-correction. This
needs to be (and is being) fixed.
> Another example, in your current Pace, you say:
>
> An APP "magic brackets" definition
> of how to traverse an APP collection.
> If this is not present
> the feed at the collection URI
> should indicate traversal.
>
> And use the following example,
>
> <ul class="traversals">
> <li>/app/collection.py?id=1&type=entries&index={index}</li>
> <li>/app/collection.py?id=1&type=entries&date={daterange}</li>
> </ul>
>
> Is this the only way to list traversals?
There is a singular form there for other elements.
> What if the traversal URI was in a link or anchor href?
I thought about this but would it make sense to
follow such a link?
> Does <base> or xml:base apply to the
> traversals in your <li> tags?
This should be specified. Good catch.
> Can I mix it up (e.g., put one traversal
> in an achor and another in li and expect clients to find both?
Sure. Not sure why you would but I can still parse it.
> What
> does <li><span>My traversal:</span> /app:collection.py/id=1</li> mean?
>
See my definition of content above.
> The more constraints you add to an xhtml microformat, the less effective
> the "XHTML is very flexible" argument becomes.
>
Ever does life require balance. I will strike a better one in
the next version.
> >The benefits do not have to apply specifically to APP to
> >be worth considering. APP is a subset to many other
> >broad problem domains such as representing data
> >on the web.
> >
> >
> I'm not interested in solving problems that are not in the atompub
> charter. I'm only interested in the benefits that apply to APP.
>
And APP does represent data on the web so many best
practices apply.
If you say "I don't care about grilling. I care about grilling
burgers." benefits of a clean spatula or not leaving raw
meat in the sun all afternoon still apply.
(Would you believe that I am pretty much a vegetarian,
having made that analogy?) :)
I do want to thank you for giving me some good specific
feedback and I agree with some it, especially that I need
to simplify and clarify the profile. This is productive.
Rob does some very nicely simple things with his XOXO.
What do you think of these:
1. member-type is indicated by a simple rel value
instead of having a list of types.
2. only one seek (traversal, search-template, whatever)
is available per collection. It uses query string only.
All parameters are optional.
- Luke
