W3C

- DRAFT -

SV_MEETING_TITLE

14 Apr 2010

Agenda

See also: IRC log

Attendees

Present
ebruchez, Leigh_Klotz, wiecha, Nick_van_den_Bleeken, John_Boyer, +0782483aaaa
Regrets
Chair
SV_MEETING_CHAIR
Scribe
wiecha

Contents


<scribe> Scribe: wiecha

Rechartering

Leigh: no news

John: don't think Steven had any either

Action item review

Nick: updated the list according to F2F and last meetings

there are a couple of resolutions w/o action items

Leigh: ok, let's assign those

<klotz> http://lists.w3.org/Archives/Public/public-forms/2010Apr/0011.html

<scribe> ACTION: Leigh Klotz to rename XForms for HTML to XForms Attributes for HTML [recorded in http://www.w3.org/2010/04/14-forms-minutes.html#action01]

<trackbot> Created ACTION-615 - Klotz to rename XForms for HTML to XForms Attributes for HTML [on Leigh Klotz, Jr. - due 2010-04-21].

Leigh: the next one, for relaxing constraints, is already done

also for p3ptype

<klotz> http://lists.w3.org/Archives/Public/public-forms/2010Apr/0010.html

Leigh: still think we need to do something on task force for access control

does anybody implement parsing those headers?

XHR will enforce this already

would suggest we add access control back on the on-going agenda

John: let's update our understanding of the requirements here

Leigh: let's otherwise close the action on Mark

and track this as a group on the agenda

action to respond to last call for XHR...we haven't discussed this but did interact with them w/o success

<trackbot> Sorry, couldn't find user - to

so we should close this action

can close steven's action to check on f2f and recharting

and also for kenneth and json issues

forms wg charter w/john boyer is done

John: as would the item on my list

for kenneth, first item on json is done, can close

John: i've also completed my action on form parts...pls close

Lyon F2F..are we meeting?

Leigh: steven has action to arrange for this

Nick: steven checking on 4-day meeting option

Leigh: so yes, we're meeting...either for 2 days for 4...will report to XCG

Why are xsd:duration and xforms:duration not supported/defined?

http://lists.w3.org/Archives/Public/public-forms/2010Apr/0007.html

John: in looking at designing forms starting from existing schemas which make use of xsd:duration have found that xforms:duration is not supported, now say processors support all xsd datatypes except for duration and a few others

but durations are popular in BPM applications :-)

it happens that the schema processor attached to our xforms processor is fine with xsd:duration

so this is just a spec issue

no type MIP was created

given it's omitted from the spec

Leigh: there are problems with comparison operations

Nick: don't know how many days in a month so comparing two durations is hard

John: yes, but this seems outside the scope of XForms

we have subtypes with ordering, but not the composite type

those are useful additions

but doesn't imply losing xsd:duration

Nick: the spec only says xsd:duration is not recommended for ...

John: Section 5.1 say's they're not supported in totality
... think this is mistaken...if I can support xsd:duration in my schema and in a type, hard to believe it's not valid in a type MIP

Leigh: supported as abstract datatype

John: yes, this means supported as base type to derive xforms:daytime and yearmonth durations

derived by restriction from xsd:duration

authors should be allowed to use xsd:duration even given its lack of convenience

Leigh: also for xforms:duration?

John: xsd:duration already allows empty string

Nick: do the same for duration as for the other types

John: agree

Leigh: what is the schema for schema for duration?

John: regular expression...

ours would be simpler...just the union of xsd:duration and empty string

could just do an erratum

optional for 1.1 processors...better than not having it at all

current behavior is not having any type restriction at all

Leigh: sounds good for basic type, why also the convenience type now?

John: would be forced to use a schema to define it myself in the app

Leigh: should this be a 1.2 module?

and then suggest implementing it in 1.1 processors...

Leigh: what's the cut between errata and 1.2?

John: for xsd:duration, claim it's not supported seems to be basically wrong

since it can be used directly in the type MIP

and our intention was to define the corresponding empty type for each supported xsd type

<klotz> Since XML Schema Part X does not define xs:duration as an abstract type, it is erroneous for XForms 1.1 to attempt to redefine it as such in a note.

John: then we could introduce the xforms type in the schema which is already not normative so updateable

Leigh: so the argument for 1.1 erratum is that it's incorrect as stated
... any opinion this should be delayed to 1.2?

(no response)

proposed resolution: amend the note stating xsd:duration is unsupported to allow for its use

<John_Boyer> In 5.1, XForms supports all XML schema 1.0 data types except... remove xsd:duration from that list

<John_Boyer> In the following note, The built-in datatype xsd:duration does not support a total ordering. Form authors are encouraged to used xforms:dayTimeDuration or xforms:yearMonthDuration instead

<John_Boyer> In 5.2.1, add duration to list of built-in primitive types in the xforms namespace

Resolution: xsd:duration and the xforms:duration including empty string is also supported

<scribe> ACTION: John_Boyer to write erratum supporting xsd:duration and xforms:duration [recorded in http://www.w3.org/2010/04/14-forms-minutes.html#action02]

<trackbot> Sorry, couldn't find user - John_Boyer

Nick: have a 1.2 item related to this

<scribe> ACTION: John_Boyer to create erratum category on the forms wiki [recorded in http://www.w3.org/2010/04/14-forms-minutes.html#action03]

<trackbot> Sorry, couldn't find user - John_Boyer

Nick: would like to get opinion on moving to xsd 1.1 part 2 data types in xforms 1.2

Leigh: is 1.1 rec?

Nick: still a WD

Leigh: think something is coming out soon

John: what is the NS for those types?

Leigh: would think it would be the same

Nick: xsd 1.1 is intended backwards compat. with 1.0

John: that's good since it would then be feasible for implementors to add those new types to schemas to provide all of xforms types

i.e. to avoid NS conflicts

Leigh: idea sounds fine depending on dates when drafts/recs published

John: also the question on the rest of xsd 1.1 not just the types

Nick: right, the types are the easy part

John: Phillip mentioned the utility of the assertion mechanism relative to xf:constraint

may cause some issues related to live validation when data are changing vs. validating one-time

Phillip: yes

John: constraints run during recalculate, schema runs during revalidate

so you'd have calculation like constraints running after the "calculate" phase is over

not saying this won't work...just not sure

Nick: just run schema processor every time

Leigh: global or tied to nodes?

need to add the general use of xsd 1.1 to the list of topics to discuss

model/@src use cases

http://lists.w3.org/Archives/Public/public-forms/2010Apr/0003.html

also 0004 and 0005

Nick: still think that form parts look like custom components, and importing models is a bit different...john seems to agree

John: yes, feel that form parts is interesting but there's also XBL

those are more generic composite controls

form parts is a design-time injection of code...little closer to runtime model/@src but does two injections (model and control)

John: the important bit is defining the injection points into the UI layer

the model position isn't really functional

so external model imports using something like @src or @import is simpler than these two alternatives

Leigh: when you generate the data layer how do you avoid name conflicts?

John: programmatic renaming at design time

so @id conflict resolution is easier for us - no runtime issues

Leigh: if we used model/@src we'd depend on unique @id's

so why is include not good enough?

John: faster for us to get it in just as a design-time feature

Leigh: why does your use case suggest model/@src vs. include?

John: not sure it does

Leigh: this is my concern...that it seems just doing something very close to include is not sufficient

John: the other reason we're doing form parts is we have two injection points...more important is the UI one

w/o doing nested forms and model-model communication, form parts gives us reuse

so it we can't do both injection points model/@src probably isn't useful

John: simple case of reusable web services declarations would be useful

Leigh: include would probably handle that though

lack of parameters on straight inclusion is a problem

Leigh: one approach is to start with something simple, other option is not not "use up" that syntax and make the real solution harder

John: I'm winding up in that latter camp

Leigh: could start with model/@src with scoping rules

John: could then expand later with a portion of a document that contains UI w/updated content

Leigh: starts looking like xpointer

John: would probably focus on the UI injection and handle the model part as a side-effect

Leigh: in summary what's the take-away from your use case and model/@src?

John: like the @id scoping resolution to get closer to form parts

seems to be unavoidable part of a solution

Leigh: some form of encapsulation

John: yes

then if we could use that import element *anywhere* and if it had UI and model elements it would "do the right thing" in terms of import

Leigh: sounds like Nick's point that this sounds like a component

John: perhaps, but some of the other component technologies are a bit more complex in separating submodels

Leigh: that's a more extreme version of encapsulation

John: right...this leads to all the model-model communication issues

import for model only, the fragments just work together

Leigh: Nick, can you pick this up by email?

not sure what's the next step

Leigh: ok, let's pick it up in the next call

Summary of Action Items

[NEW] ACTION: John_Boyer to create erratum category on the forms wiki [recorded in http://www.w3.org/2010/04/14-forms-minutes.html#action03]
[NEW] ACTION: John_Boyer to write erratum supporting xsd:duration and xforms:duration [recorded in http://www.w3.org/2010/04/14-forms-minutes.html#action02]
[NEW] ACTION: Leigh Klotz to rename XForms for HTML to XForms Attributes for HTML [recorded in http://www.w3.org/2010/04/14-forms-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/04/14 16:05:57 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: wiecha
Inferring ScribeNick: wiecha
Default Present: ebruchez, Leigh_Klotz, wiecha, Nick_van_den_Bleeken, John_Boyer, +0782483aaaa
Present: ebruchez Leigh_Klotz wiecha Nick_van_den_Bleeken John_Boyer +0782483aaaa

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Agenda: http://lists.w3.org/Archives/Public/public-forms/2010Apr/0008.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 14 Apr 2010
Guessing minutes URL: http://www.w3.org/2010/04/14-forms-minutes.html
People with action items: john_boyer klotz leigh

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]