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

 


Help: OASIS Mailing Lists Help | MarkMail Help

uiml message

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


Subject: Re: [uiml] Summary of issues raised by Takashi Endo and suggested UIML 4.0 changes



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 -----
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 < robbie@c-lab.de> 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" <jhelms@gmail.com>
To: "Robbie Schaefer" <robbie@c-lab.de >
Cc: <uiml@lists.oasis-open.org>; "Jo Vermeulen" <jo.vermeulen@uhasselt.be >
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 <robbie@c-lab.de > 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" <jhelms@gmail.com>
>> To: "Robbie Schaefer" <robbie@c-lab.de>
>> Cc: < uiml@lists.oasis-open.org>
>> 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 < robbie@c-lab.de> 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
>>
>>



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