Just a small issue: The changes Jo applied to the DTD are
not yet reflected in Appendix D "UIML 4.0 Document Type Definition"
All the best,
Robbie.
--
_/ Dr. Robbie
Schaefer _/ Phone: +49 5251
60-6107 _/
_/ Visual Interactive Systems _/ Fax: +49 5251
60-6065 _/
_/ C-LAB Fuerstenallee
11
_/
_/
_/ D-33102 Paderborn
_/ URL: http://www.c-lab.de _/
----- Original Message -----
From:
Jo
Vermeulen
To: Robbie Schaefer
Cc: Jim Helms ; ; Jan
Meskens ; Kris Luyten
Sent: Friday, December 07, 2007 5:09
PM
Subject: Re: [uiml] Summary of issues
raised by Takashi Endo and suggested UIML 4.0 changes
I did the same for d-template-param's, and also changed the
syntax (there was a small mistake in the examples, now d-template-param
elements don't have children, but instead a name attribute).
The
d-template-param element is now empty by the way (I'm using DTD's EMPTY
indicator).
I also changed the example (Listing 10). It would be
great if you guys could have another look at it to make sure it is okay
now.
-- Jo
On Dec 5, 2007 10:31 AM, Robbie Schaefer < > wrote:
Hi,
I
attached the modified specification. I decided to rename the
"id"-attribute of the variable-element into "name", to avoid
confusion.
Variables don't need a unique identifier, since naming
conflicts are
resolved with the scoping rules and real ID's would be too
restrictive.
I changed sections 6.8.5.1, 6.9 and the variable-element in the DTD.
All
should be visible with track changes.
BR,
Robbie.
--
_/ Dr. Robbie Schaefer
_/ Phone: +49 5251 60-6107 _/
_/ Visual
Interactive Systems _/ Fax: +49 5251 60-6065 _/
_/
C-LAB Fuerstenallee 11 _/
_/
_/ D-33102
Paderborn _/ URL: http://www.c-lab.de
_/
----- Original Message -----
From: "Jim Helms" <>
To: "Robbie
Schaefer" <
>
Cc: <>;
"Jo Vermeulen" <
>
Sent: Tuesday, December 04, 2007 3:23 PM
Subject: Re: [uiml]
Summary of issues raised by Takashi Endo and suggested
UIML 4.0
changes
> Robbie,
>
> Yes, go ahead and update
that version. I have a version I am working,
> but I have not
touched the variable section so it should be easy to
>
merge.
>
> Thank you!
> Jim
>
> On 12/4/07,
Robbie Schaefer <
> wrote:
>> Hi,
>>
>> > That is a good
point. I like the way DISL handles this, but we have
>> >
two considerations: 1) UIML sets a precedent with the
<property>
>> > element that establishes "name" as the way
to reference an existing id
>> > without conflicting; and 2) the
additional reference attribute still
>> > leaves us with the
issue of having conflicting id's. The DISL
>> > approach
is very good for readability, but I think the problem Mr.
>> >
Endo had was related to limitations of the DOM specification that
only
>> > allows you to look up single elements by id.
>>
>> OK, now I got it :-)
>> I could update the
relevant parts WRT variables (Section 6.9 and the
>>
DTD).
>> Do I have the most current version?
(uiml-core-4.0-draft_RS021007.doc )
>>
>> All the
best,
>> Robbie.
>> --
>> _/ Dr. Robbie
Schaefer _/ Phone: +49 5251 60-6107
_/
>> _/ Visual Interactive Systems _/ Fax: +49 5251
60-6065 _/
>> _/ C-LAB Fuerstenallee 11
_/
_/
>> _/ D-33102 Paderborn
_/ URL: http://www.c-lab.de _/
>>
>> -----
Original Message -----
>> From: "Jim Helms" <>
>> To:
"Robbie Schaefer" <>
>> Cc: <
>
>>
Sent: Monday, December 03, 2007 3:38 PM
>> Subject: Re: [uiml]
Summary of issues raised by Takashi Endo and
>> suggested
>> UIML 4.0 changes
>>
>>
>> >
Robbie, thanks for you input! Additional comments below.
>>
>
>> > On 12/3/07, Robbie Schaefer < > wrote:
>>
>> > Suggested change: add an attribute to <variable> called
"id-ref"
>> >> > that
>> >> > is used to
reference a variable after it is declared.
>> >>
>>
>> We had thought of this when designing DISL and the current sulution
in
>> >> the
>> >> UIML-DTD is that we have an
additional attribute for the variable
>> >>
which
>> >> specifies wether it is used as a declaration or
as a reference:
>> >> reference
>> >>
(true|false) "true".
>> >>
>> >> However if
all agree that id-ref is the more proper/consitent solution
>>
>> (since it is used in other UIML-elements in the same fashion) I
could
>> >> go
>> >> through the relevant
parts in the spec and change the examples and
>> >>
explanations.
>> >>
>> >> The point in favor
of the "reference"-Attribute is that it is
>> >>
implicitly
>> >> set
>> >> true, so that only
once, for the declaration, a variable needs to
>> >>
state
>> >> the
>> >> reference attribute,
which IMHO adds to the readability of the
>> >>
UIML-document.
>> >>
>> >> Anyway, I am open
to both options.
>> >
>> > That is a good point.
I like the way DISL handles this, but we have
>> > two
considerations: 1) UIML sets a precedent with the
<property>
>> > element that establishes "name" as the way
to reference an existing id
>> > without conflicting; and 2)
the additional reference attribute still
>> > leaves us with the
issue of having conflicting id's. The DISL
>> > approach
is very good for readability, but I think the problem Mr.
>> >
Endo had was related to limitations of the DOM specification that
only
>> > allows you to look up single elements by id. One
way to solve this
>> > and use the DISL scheme would be to use a
different attribute as the
>> > name of the variable and have
an id attribute that's sole purpose is
>> > to uniquely identify
the element within the document.
>> >
>> > Whatever
we decide, I believe we should choose a consistent scheme to
>>
> handle this for <property>, <variable>, and <param>.
Thus using id in
>> > the declaration and name for the
references may serve for this version
>> > of the specification
with further improvements to come in the next
>> >
version.
>> >
>> > Just my thoughts :)
>>
>
Jim
>>
>>
