Re: display questions

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

xmile message