Re: [widget] relax NG schema
On Wed, Sep 2, 2009 at 12:19 PM, Marcos Caceresmarc...@opera.com wrote: Simon Pieters wrote: I've now run a check on the schema based on the tests and it seems to be correct. I'd appreciate review! I believe RNC should be served as application/relax-ng-compact-syntax rather than text/plain. Yeah, but for now it's better for us humans so we can just view the content in the browser. Having to download the file, open it in editor, etc, etc. is a PITA. Once the document matures and stabilizes, then we will serve it properly. +1 for waiting to stabilizes Xmlizer
Re: [widget] relax NG schema
On Mon, Aug 31, 2009 at 4:10 PM, Robin Berjonro...@berjon.com wrote: On Aug 31, 2009, at 15:58 , Marcos Caceres wrote: As we have partitioned the PC spec into multiple specs, the RelaxNG schema is no longer complete (e.g., excludes updates and warp). I suggest we rip the relax NG schema out of the PC spec and republish it as a non-normative note. That way, we can update it separately if we spawn any new specs or if things change. That's one option. Another option is to define it using groups, and have the other specs compose their additions in the groups. It's not very hard to do. +1 for using groups Xmlizer
Re: CfC: to publish a new WD of the DOM3 Events spec; deadline Sep 4
On Fri, Aug 28, 2009 at 5:28 PM, Arthur Barstowart.bars...@nokia.com wrote: This is a Call for Consensus (CfC) to publish a new WD of the DOM 3 Events spec: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is Sep 4. Please publish it and thanks for your contribution Doug to this spec It will always be time to make detail comment after that (it's always easier than following a moving target) Xmlizer
Re: Request for Comments: FPWD of Widgets 1.0: URI Scheme spec
Dear, Very interesting part of the whole Widget Sorcery Here are few comments 1) In the same spirit as WARP, it would be interesting to make HTML5 reference, an informative one 2) Probably the link between authority and opaque-autorithy should be clearer 3) Update reference to Working Draft 28 May 2009 for Widgets-PC 4) s/RFC5234/RFC 5234/ I'm not sure to fully understand this requirement [[ Must be independent of any file system Addressing based on this scheme must only map onto Zip relative paths and remain independent of any file system on which the widget may be stored. ]] Does it mean that, it is case insensitive for example ? Xmlizer On Thu, Jun 18, 2009 at 4:19 PM, Arthur Barstowart.bars...@nokia.com wrote: To: public-webapps@w3.org BCC: www-...@w3.org, public-pkg-uri-sch...@w3.org Reply-to: public-webapps@w3.org On June 18, the Web Applications WG published a First Public Working Draft of the Widgets 1.0: URI Scheme spec: [[ http://www.w3.org/TR/2009/WD-widgets-uri-20090618/ Abstract Many specifications in the Web stack depend on a context being defined that includes a current URI. This is easily provided for documents retrieved over HTTP, or from the local file system, but is currently undefined for documents extracted from within a widget package. Such a limitation has a number of implications which this document intends to address. Introduction This specification defines the widget URI scheme for use inside widgets or other such applications of web technology that do not run on the web. ]] If you have any comments, please send them to public-weba...@w3.org. -Regards, Art Barstow P.S. BCC was used for TAG and PKG-URI mail lists to reduce cross-posting
Re: New draft of Widgets: Access Requests Policy
Hi Robin, Sorry for disturbing : there is a bunch of space problem in the spec : probably it is only depending on your build process For example : * ASTERISK (*)character * Path Language (XPath)Version 1.0 * Steve DeRoseW3C Recommendation Reference * probably you should consider referencing RFC 2818: HTTP Over TLS for HTTPS * [Widgets-Reqs] is now dated from 30 april 2009 instead of september 2008 * The same applies for [Widgets-DigSig] * [Widgets-Updates] is now dated from 14 April 2008 Process question : since your making refrence to HTML5 normatively, do you expect HTML5 to become a REC before Widgets 1.0: Access Requests Policy Some precision : Please add at the top of section 3 The access element, that the access element in the namespace http://www.w3.org/ns/widgets; Regards Xmlizer On Fri, Jun 5, 2009 at 6:44 PM, Robin Berjon ro...@berjon.com wrote: Hi, a new ED of WARP is up, including the following changes based upon prior discussion: - a new, nicer name - better definitions - more fleshed ou requirements - more detailed policy - fixes to the element definition - fixes to the processing model - better acknowledgements Share and Enjoy at http://dev.w3.org/2006/waf/widgets-access/ -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Mutation events replacement
On Thu, Jun 4, 2009 at 12:07 PM, Jonas Sicking jo...@sicking.cc wrote:
Here's an API that might work:
The following methods are added to the Document, Element and
DocumentFragment interfaces:
addAttributeChangedListener(NodeDataCallback);
addSubtreeAttributeChangedListener(NodeDataCallback);
addChildlistChangedListener(NodeDataCallback);
addSubtreeChangedListener(NodeDataCallback);
I would go for
addSubtreeElementChangedListener for this one since a modification to an
attribute in the subtree does not trigger it
addTextDataChangedListener(NodeDataCallback);
removeAttributeChangedListener(NodeDataCallback);
removeSubtreeAttributeChangedListener(NodeDataCallback);
removeChildlistChangedListener(NodeDataCallback);
removeSubtreeChangedListener(NodeDataCallback);
and removeSubtreeElementChangedListener...
removeTextDataChangedListener(NodeDataCallback);
And add the following interface:
[CallBack=FunctionOnly, NoInterfaceObject]
interface NodeDataCallback {
void handleEvent(in Node node);
};
These are *not* DOM-Event listeners. No DOM Events are created, there
are no capture phases or bubbling phases. Instead you register a
listener on the node you are interested in being notified about, and
will get a call after a mutation takes place. The listeners are called
as follows:
'AttributeChanged': Called when an attribute on the node is changed.
This can be either a attribute addition, removal, or change in value.
If setAttribute is called the 'AttributeChanged' listener is always
called, even if the attribute is given the same value as it already
had. This is because it may be expensive to compare if the old and new
value was the same, if the value is internally stored in a parsed
form.
'SubtreeAttributeChanged': As for 'AttributeChanged', but called not
just for attribute changes to the node, but also to any descendants of
the node.
'ChildlistChanged': Called if one or or mode children are added or
removed to the node. So for example when innerHTML is set, replacing
10 existing nodes with 20 new ones, only one call is made to the
'ChildlistChanged' listeners on that node.
'SubtreeChanged': Same as 'ChildlistChanged', but called not just for
children added/removed to the node, but also to any descendants of the
node.
'TextDataChanged': Called when the data in a Text, CDATASection or
ProcessingInstruction, is changed on the node or any of its
decendants.
The exact algorithm would go something like this:
The implementation contains a global list, pendingCallbacks. Each item
in pendingCallbacks is a tuple: callback, node.
The implementation also contains a flag, notifyingCallbacks, which
initially is set to false.
If an attribute is changed on node N, perform the following steps:
1. For each 'AttributeChanged' callback, C, registered on N, add an
item to the end of pendingCallbacks with the value C, N
2. For each 'SubtreeAttributeChanged' callback, C, registered on N,
add an item to the end of pendingCallbacks with the value C, N
3. Set N to N's parentNode.
4. If N is non-null, go to step 2.
5. If notifyingCallbacks is set to true, or pendingCallbacks is empty,
abort these steps.
6. Set notifyingCallbacks to true.
7. Remove the first tuple from pendingCallbacks.
8. Call the handleEvent function on the callback in the tuple, with
the 'node' argument set to the node from the tuple.
9. If pendingCallbacks is not empty, go to step 7.
10 Set notifyingCallbacks to false.
A similar algorithm is run when children are added and/or removed from
an element/document/document-fragment, just replace 'AttributeChanged'
with 'ChildlistChanged', and 'SubtreeAttributeChanged', with
'SubtreeChanged'.
And when Text/CDATASection/ProcessingInstruction
Please add Comment too
nodes have their
contents modified the same algorithm is run, but without step 1, and
with 'SubtreeAttributeChanged' replaced with 'TextDataChanged'.
There's a few of properties here that are desirable, and one that is
sub-optimal.
First of all no notifications are done until after the implementation
is done with the mutations. This significantly simplifies the
implementation since all critical work can be done without worrying
about script performing arbitrary operations in the middle.
Second, all callbacks are notified in the order mutations happen in
the tree, even when another callback performs further mutations. So if
a callback for 'ChildlistChanged' sets a attribute on the newly
inserted node, the other callbacks are still going to get first
notified about the node being inserted, and then about it having an
attribute set. This is thanks to the notifyingCallbacks flag.
Third, these notifications should be significantly faster. Since there
are no DOM Events, there is no need to build propagation chains.
There's also no need to recreated the old attribute value, or to fire
one event for each node if multiple nodes are added and
Re: Mutation events replacement
On Thu, Jun 4, 2009 at 1:42 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jun 4, 2009 at 4:37 AM, mozer xmli...@gmail.com wrote: On Thu, Jun 4, 2009 at 12:07 PM, Jonas Sicking jo...@sicking.cc wrote: Here's an API that might work: The following methods are added to the Document, Element and DocumentFragment interfaces: addAttributeChangedListener(NodeDataCallback); addSubtreeAttributeChangedListener(NodeDataCallback); addChildlistChangedListener(NodeDataCallback); addSubtreeChangedListener(NodeDataCallback); I would go for addSubtreeElementChangedListener for this one since a modification to an attribute in the subtree does not trigger it the 'SubtreeAttributeChanged' callbacks are called whenever an attribute is the subtree below the node where the callback is registered is changed. Is that not what you need? I.e. in a DOM like body div p here's some text /p /div /body If I call div.addSubtreeAttributeChangedListener(doStuff); then doStuff is called if someone sets an attribute on the p element. We're in agreement here ! That's why I would go for a name stating explicitly that it is about ELEMENT in the subtree and not Whatever in the subtree And when Text/CDATASection/ProcessingInstruction Please add Comment too Yup. / Jonas Xmlizer
Re: Widget instances and widget invocations
Dear, On Thu, Apr 30, 2009 at 4:45 PM, Robin Berjon ro...@berjon.com wrote: Hi, a) the UA has somehow allowed me to pick which instance I run, I get back what I put for the right instance b) the UA has become confused, I get both values, or something broken, or nothing c) the UA has a single origin mapped to my widget, I get the last write I would also add as a variant of a) (which is probalby more realistic) is that When you kill widget 1 it asks you if you want to save your data : Y1/N1 When you kill widget 2 it asks you if you want to save your data : Y2/N2 Then you will have Y1/Y2 -- data of 2 ; Y1/N2 -- data of 1; N1/Y2 -- data of 2 ; N1/N2 -- previous data (or default if it was the first invocation ever) Then the UI may propose to the user to always save the preference and then you will get c) behaviour My two cents Xmlizer
Re: numbering
well I wonder why this regex disallow all multiple of 10 signature10.xml is not possible any more Xmlizer On Thu, Mar 5, 2009 at 6:10 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: I see, perhaps we can combine the text I proposed with a variant on the bnf you mentioned; signature[0-9]*[1-9].xml and add to my proposal the additional text: If a widget resource contains signatures that are not consistent in the number of digits in the names then the result of ordering will be implementation dependent. regards, Frederick Frederick Hirsch Nokia On Mar 5, 2009, at 12:03 PM, ext timeless wrote: On Mar 5, 2009, at 9:15 AM, I wrote: The proposal is to only allow [1-9][0-9]*, which should solve this. On Thu, Mar 5, 2009 at 5:59 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: This does not seem quite right since it requires 10 or more signatures? e.g. disallows signature01.xml, signature02.xml etc and requires signature10.xml etc I'm not certain about the []* notation. I was hoping for leading non-zero digit and 0 or more digits I propose the following alternative in section 5.3 Naming convention for a distributor signature:signature [0-9]* .xml Every distributor signature MUST have the same number of digits in the file name and use leading zeros for numbers less than the maximum numeric value. This is to enable consistent sorting. To give an example, if nine distributor signatures are expected the numbers should range from 01 to 09, e.g. signature01.xml to signature09.xml. --- Does this make sense? That'd work too, and i suppose would be easier on a sorter since it could do an alpha sort. Although you need to explain what to do if there are only signature01.xml and signature1.xml, does the engine always favor the longest string and ignore all shorter sets? Either way, validators need instructions, for yours it would need to warn about signatures which have the wrong number of digits.
