[
Lists Home |
Date Index |
Thread Index
]
Bullard, Claude L (Len) wrote:
> From: Robin Berjon [mailto:robin.berjon@expway.fr]
>>I don't see it as strong vs weak, though I do think that it is strong in a
>>number of industries. I see it as happening vs not happening, and it is
>>happening. If you have to pay royalties to send your SVG to phones made by
>>vendor foo, and vendor foo has a large market share, you're basically stuck.
>
> Vendor foo can always make you do that. Standards compliance is a voluntary
> issue. Vendor foo needs a stronger incentive one of which would be a strong
> standard for an infoset binary that works for multiple applications and has
> no encumbrances.
Yes of course, sorry if I was too fast in my description of the situation. Here
are two scenarii from an imaginary standard consortium discussing their usage of
imaginary vocabulary DahutML, with vendor foo being the big one, and others
smaller enough to not have that much of a choice:
-No Acknowledged Binary Infoset Standard Scenario
vendor foo: DahutML is what we need, but as you all know it's too verbose so we
need to binarize it. Thankfully our research team has come up with this
binary format that makes it smaller. We request its admission.
vendor bar: But... that format is kludgy, your figures are unprovable, and it
flies in the face of all future improvements planned for DahutML 2.0!
vendor foo: Bah, what are you saying! Anyway, that's what we'll be shipping so
you better standardize it.
[smaller vendors a through z remain silent]
-Acknowledged Binary Infoset Standard Scenario
vendor foo: (says same as above)
vendor bar: (says same as above, followed by) And anyway, there's already a
much better and widely accepted standard for that. I motion that we should
support that and nothing else.
[clamoring vendors a through z agree]
And as you'll guess, in scenario B vendor foo, however powerful, accepts for a
variety of reasons. You could say that I needn't depict those scenes as all here
could have guessed. I wished however to stress the fact that that very first
scene is precisely what is presently going on in some non-negligible consortia.
>>What do you mean by requirements statement?
>
> I mean one which all of the parties at the W3C can get behind. If you
> have one already, so much the better. But the objection I seem to hear
> to this is that a binary infoset generic enough that everyone can use
> it might be too general and therefore, won't meet the stringent requirements
> of applications where it is most needed.
I'm quite confident that I can prove that such a format exists, in fact until
proven wrong I know that it exists. Given the upcoming threat I see I'm willing
to put a lot of personal energy into that, but I'd rather not do that on my own.
>>I work for the people that hold those patents. Speaking for myself, I think it
>>may be possible to find an un-encumbering solution to standardize something
>>BiM-like. Apart from that, dodging patents in that area is going to be
>>increasingly difficult.
>
> Yuck. That is what scares me. It could mean they got there early in a domain where
> there are 1.25 useful solutions, and patented that. If so, this is a spilt milk situation.
> It depends on the specific patents and alternatives.
It also depends on who holds the patents and what they are willing to do about
that. Again, speaking *only* for myself, we've already gone RF in some areas.
Provided an appropriate business model, it could be possible to find solutions
to the patent problem.
> A generic binary for markup has been a topic since before the web. Somehow,
> it always stalls out as Dan Connoly noted. What you are saying is that:
>
> 1. MPEG has one and it is encumbered.
> 2. MPEG may have already cornered the optimum approach.
> 3. Other approaches are already growing in isolated domains.
> 4. We may end up with a set of non-interoperable defacto
> suboptimum approaches.
> 5. We should try to create an interoperable open standard approach
> that is reasonably optimum for everyone (that is the Web3DC
> position as well if I understand what Don Brutzman has said.)
>
> So, if I understand you correctly, time is not on the side of
> the W3C or others who need this. You are saying that they don't
> need to justify that need; they need to get together and decide
> if a common standard royalty free solution is possible and do
> it as soon as possible.
You are phrasing it more abruptly than I would, not because I desire to tread on
eggs but because 1) I've had many stalled debates on binary infosets before and
seeing that this one is going well I'd like to keep it that way, and 2) there's
a fine line to walk to get it right, and I really am afraid of it all going
wrong. But basically, yes, you have summarized my position very well.
> Ummm... why was this brought to the TAG? This seems like a
> subject for requesting a new WG, not an architecture issue?
The issue is attributed as if I requested it, but I didn't ask the TAG to
consider it an issue precisely because I wasn't certain that that was the right
group to bring it up with. However when I posted I was looking at
interoperability issues regarding the use of binary infosets (which are
mentionned in the webarch draft) in open situations. I knew that given a single
format, interop wasn't much of a problem at least over HTTP (you have content
negotiation), but I also knew that binary infosets were appearing all over the
map and was wondering if the TAG was aware of the problem. When Don Brutzman
brought it up again, it was turned into an issue.
Now that the issue's there -- which I think is a good thing -- I must say that
I'm pleasantly surprised at how sanely xml-dev is discussing it. Judging from
earlier discussion on this topic, I was increasingly concerned that it would
only be possible to have an honest discussion about it after the de facto chaos
had occurred.
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
