OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xmile message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: display questions


Hello Billy,

Thanks for the reply - that nicely summarizes the issue.

What I've been trying to get at is that I would prefer us to keep the
spec as small as possible - the problem with having more options/a
larger spec is that everyone who implements it will use a different
subset of features.  So - the whole spec will be used, but as a number
of slightly-overlapping implementations.  You also say that in
different words.

I understand the sentiment that Steve has expressed that perfect is
the enemy of good - but I think there is a similar maxim that goes
something like 'full inclusion is the enemy of innovation'.  Lets try
to keep this small so that more people can implement it and come up
with novel uses & extensions, rather than trying to anticipate
everything that can be done (imperfectly).  We're trying to write a
spec that can capture 80%-90% of SD models, which I think is a useful
lens to frame these issues.

yours,
Bobby




On Mon, Jun 9, 2014 at 2:15 PM, Billy Schoenberg
<bschoenberg@iseesystems.com> wrote:
> Hi Bobby,
>
> Let me deal with your second e-mail first because that gets to the meat of
> the issue.
>
> The meat of this issue is what we conceptualize the XMILE view as.  Is the
> XMILE view the representation of a single screen within a software program
> or potentially multiple screens? (think of the isee interface layer in its
> entirety as a view for the model, same for the stock/flow diagram as a view
> for the model, each with multiple pages)
>
> If we start by taking your suggestion of a view being a single screen within
> a program, then you are correct it makes no sense to do navigation based on
> sub-sections of the screen, but if we conceptualize the XMILE view as
> potentially containing multiple screens then navigation within a view as
> well as among views becomes necessary.
>
> The conceptualization of a view as a single screen is more restrictive and
> forcing that definition requires 'mapping' or some other transformation of
> data on input or output from its native form to XMILE, while taking the more
> encompassing conceptualization of views does not impose any 'mapping' or
> data transformation from other vendors.
>
> I think this comes down to the same question which we have been debating on
> these e-mails for the past few weeks and in the meetings for the entirety of
> this process, which is 'Does the spec encode a single 'correct' way to do
> everything while remaining smaller and simpler, or does it encode many ways
> each equally 'correct' to do anything while ballooning in size and gaining
> in complexity?"
>
> To play both sides of that argument a simple spec is easier to implement,
> and therefore may entice more implementations, while a larger more complex
> spec is harder to implement and therefore may prevent more implementations,
> but on the reverse a larger more complex spec with multiple correct ways to
> do things may lead to many implementations of the spec that don't work well
> with each other, because all of the optional portions which vendor A relies
> on vendor B does not implement.  I think for each of these issues that we
> are having right now (sub-model-of/to, this one with views, etc), we need to
> answer the question I posed in the paragraph above.
>
> Billy
>
>
> On Mon, Jun 9, 2014 at 1:51 PM, Bobby Powers <bobbypowers@gmail.com> wrote:
>>
>> I guess more fundamentally there is a lot of navigation-based stuff
>> based off of the idea of pages/indexes inside a view, rather than
>> multiple views, which is isee-specific (or an artifact of this spec
>> originating at isee, however you want to say it).  I'm not exactly
>> sure how to resolve that - the nicest way across all vendors might be
>> to have isee map its current files from single views into multiple
>> views that happen to be rendered next to each other on the same
>> canvas.
>>
>> yours,
>> Bobby
>>
>> On Mon, Jun 9, 2014 at 1:38 PM, Bobby Powers <bobbypowers@gmail.com>
>> wrote:
>> > Hi Billy,
>> >
>> > I see that you added some pieces today, I have a few concerns
>> > (especially seeing as if we're holding off on controversial changes
>> > before voting on Friday, as Will mentioned).  First, you added:
>> >
>> > "In order for XMILE views to be more easily navigated views are
>> > required to specify:
>> >
>> > home_page<int> default: 0- The index of the printed page which is
>> > shown when any link with the home_page target is executed
>> >
>> > home_view<bool> default: false – A marker property which is used to
>> > determine which view is navigated to when any link with the target
>> > home_view is executed. Only one view for each view type is allowed to
>> > be marked as the home_view."
>> >
>> > This seems very isee-specific.  I don't know of any other vendor that
>> > uses index of printed pages - can we leave this out of the spec and
>> > isee can use these it with the 'isee:' namespace prefix?
>> >
>> >
>> > Second, is the visual effects on <link>.  Values are listed as
>> > "dissolve, checkerboard, bars, wipe_left, wipe_right, wipe_top,
>> > wipe_bottom, wipe_clockwise, wipe_counterclockwise, iris_in, iris_out,
>> > doors_close, doors_open, venetian_left, venetian_right, venetian_top,
>> > venetian_bottom, push_bottom, push_top, push_left, push_right".  This
>> > is very arbitrary and isee-specific (similar with to_black).  I think
>> > there needs to be a place for isee to document the isee-specific
>> > values it recognizes in attribute values, but that might not be in the
>> > middle of the industry's spec.  Maybe we should have appendixes for
>> > vendor-specific values?
>> >
>> > yours,
>> > Bobby
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]