Re: Spec review, part 1

>
> Some comments below:
>
> 1. Introduction
>
> This is not new but I have never liked the use of "XForm" (singular).
> The only place in the spec doing this is here "An XForm allows" ->
> suggesting using "XForms allows". Need action for this.
>
> Done
>

Good!

> 2. JSON
>
> Are we sure we want to specify our own JSON mapping? Aren't there
> multiple competing options? I remember reading some skepticism about
> this at XML Prague.
>
> If the map functionality in XQuery/XSLT gets fleshed out and they make it
> usable for us (be able to use path expressions), maps would be a better
> approach in my opinion.
>
>  There is good (bit dated) blog post of Eric Van der Vlist about it
> http://eric.van-der-vlist.com/blog/2012/02/25/xdm-maps-should-be-first-class-citizens/
>

Ok so that's something the group needs to discuss.

>
> 3. CSV
>
>
> Do we really want to do this?
>
> No opinion
>
>
> 4. Common Attributes: I don't think the changes discussed last week
> wrt moving more attributes to Commons are in, right?
>
> Is in there and John made some changes
>

Yes that's good.

>  5. Functions
>
> 5.1. Do we really need "override"? what was the purpose of this?
>
> I think it is a handy feature (XSLT also has it). This allows form authors
> to easily define fallback implementations if a processor doesn't implement
> a certain function.
> It also allows flexible override functionality when including external
> function libraries.
>

Ok. I am a bit more comfortable if XSLT has it. BTW I see that XSLT says
"The optional override attribute defines what happens if this function has
the same name and arity as a function provided by the implementer or made
available in the static context using an implementation-defined mechanism".
It's not clear to me here if a user-defined function can override standard
functions, as the wording "made available in the static context using an
implementation-defined mechanism" could imply they are talking about custom
extension functions.

>  5.2. I don't think we have ruled out my proposal to simplify this with
> no nested elements (i.e. no <var>, <sequence>, <script>). Need to
> discuss.
>
> We need indeed to put this back on the agenda
>

Yup.


>
>
> 6. Repeat over atomic values
>
> In 9.3.3, we need to be more clear about how atomic values "match"
> (provide example) upon repeat sequence update. Need action to improve
> this.
>
> See
> http://www.w3.org/MarkUp/Forms/wiki/index.php?title=XForms_2.0&diff=3699&oldid=3696(also added text that there is no context node if you repeat over non-nodes)
>

That's good, what I thought was mainly missing was a description of the
repeat sequence update when the sequence changes (insert, delete, etc.).
But I see that the text was not super specific for nodes either, i.e.
everything rests on the notion of "repeat items corresponding to the new
items". Not sure if we want to be more specific here.

>
> 7. "xforms-script-language-not-supported-exception"
>
> A bit shocked by the length of this event…
>
> Suggestion?
>

Maybe xforms-not-supported-exception? Still ugly, a bit shorter. That could
be reused in other places.

>
> 8. Insert
>
> We talked about improving this action, maybe with an "into" attribute.
> Should we still consider this? If so need action to complete it.
>
> 9. show="embed"
>
> I think the current text is still very incomplete. Need to
> discuss/action to complete it.
>
> Leigh added this just before he left the group, I also expressed my
> concerns about this text at the last editorial meeting.
>

So that would be one more agenda item. Maybe implementors (XSLTForms,
betterFORM) could provide feedback as well?

-Erik

>
> In general, there are some wording issues (tenses, in particular). How
> do we fix that?
>
> I haven't yet reviewed the XPath Expression Module.
>
> I don't know if any of the above needs to be addressed for a FPWD.
>
> -Erik
>
> [1] http://goo.gl/xi8IW
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>
> ------------------------------
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>