James M Snell wrote:
> PaceProfileAttribute > No significant support. > DISPOSITION: Close it
It would be nice if folks would actually comment in detail on these. They really have not been adequately discussed. It would be helpful if those who are -1 to the idea of profiles could offer a bit more insight into their positions.
If you're +1 to the concept, but -1 to the syntax, what syntax do you think is better?
If you're -1 to the concept, why?
- If you just don't think it is necessary, fair enough
It has yet to been explained to me why they might be necessary - so why do I need to think they're not necessary to justify an objection? ;)
I've also made a (I believe significant) point in conflating @profile to @rel that hasn't been addressed (imho). The very useful thing I've seen is that @profile could be used to flag an archive. But how that's essentially different from using @rel I don't know.
And I still don't understand why @version and @profile have anything to do with each other.
- If you just think it's not part of the core and can be added later,
fair enough, but that doesn't get around the fact that the current
spec, as written, does not allow extensions to change containment
requirements and therefore does not provide for a necessary aspect
of profile support (the ability to change containment requirements)
I don't see that as a feature as things stand, this idea that a piece of metadata can/should alter cardinality or some other aspect of the grammar. Give me a sound set of evaluation rules and what you're asking for is probably cool. Without them, no.
In another thread, you mentioned that profiling is not difficult, wrt conflict resolution. I think you have to think of that difficulty with respect to things like Sam's <div> approach to XHTML or wf feed XML. What you're asking for here seems to hold a higher bar than what is needed for either of those - in particular it won't surprise me if conflict resolution requires programming with exceptions or heuristics in the absence of people willing to write conflict solvers.
My general opinion on this type of stuff, is that if you can't determine sound evaluation rules, it has to be because the domain or the nature of the data dictates it - in this case I think vagueness on conflict resolution is an indicator that the feature being proposed is woolly. A resulting suspicion is that @profile metadata will be highly lossy in heavy aggregation and remixing scenarios, which I speculate will explode over the next 18 months. In short I'm concerned @profile is feature that will not self-interoperate.
cheers Bill
