You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Andrew Grieve <ag...@chromium.org> on 2014/02/12 23:00:35 UTC
XML Namespaces
Maybe I'm crazy, but I can't stand them. I don't think they add any value,
and are a cause of confusion.
So... I'd like to:
A: Remove xmlns="http://www.w3.org/ns/widgets" from our config.xml template
B: Change xmlns:cdv="http://cordova.apache.org/ns/1.0" -> xmlns="
http://cordova.apache.org/ns/1.0"
C: Revert the commit that enforces the namespace to exist.
This will allow us to add new tags & attributes to cordova.xml without
"violating" XML namespace rules.
Does anyone hate this idea?
Re: XML Namespaces
Posted by Gorkem Ercan <go...@gmail.com>.
I am not liking it.
JBoss tools actually maintains a w3c xsd and maps the "
http://www.w3.org/ns/widgets" namespace to that XSD. Through this mapping
tools can provide content assist, validation etc. When this namespace
disappears we loose all the benefits. I would be OK with a planned
replacement of the namespace as suggested on B as long as we can maintain
an XSD for it.
Validation against an XSD is probably the main benefit of using xml on
config.xml at least for me.
On Wed, Feb 12, 2014 at 5:00 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Maybe I'm crazy, but I can't stand them. I don't think they add any value,
> and are a cause of confusion.
>
> So... I'd like to:
> A: Remove xmlns="http://www.w3.org/ns/widgets" from our config.xml
> template
> B: Change xmlns:cdv="http://cordova.apache.org/ns/1.0" -> xmlns="
> http://cordova.apache.org/ns/1.0"
> C: Revert the commit that enforces the namespace to exist.
>
> This will allow us to add new tags & attributes to cordova.xml without
> "violating" XML namespace rules.
>
> Does anyone hate this idea?
>
Re: XML Namespaces
Posted by Jesse <pu...@gmail.com>.
A. -1 We follow the widget spec, so why not use the namespace?
B. What is the cdv::namespace used for? I am okay with getting rid of it
completely, but not making it the default namespace for an app's config.xml
...
C. I am okay with removing the check, really this is just a matter of
strictness. All templates for 3.4.0 should now be using the widget spec
namespace, so this will likely not be an issue unless it really is an issue
... like someone adding a new platform, and not following the spec, in
which case this would be a good thing to catch ... I am fine either way.
What tags+attributes do you want to add?
@purplecabbage
risingj.com
On Wed, Feb 12, 2014 at 2:00 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Maybe I'm crazy, but I can't stand them. I don't think they add any value,
> and are a cause of confusion.
>
> So... I'd like to:
> A: Remove xmlns="http://www.w3.org/ns/widgets" from our config.xml
> template
> B: Change xmlns:cdv="http://cordova.apache.org/ns/1.0" -> xmlns="
> http://cordova.apache.org/ns/1.0"
> C: Revert the commit that enforces the namespace to exist.
>
> This will allow us to add new tags & attributes to cordova.xml without
> "violating" XML namespace rules.
>
> Does anyone hate this idea?
>
RE: XML Namespaces
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Sat Feb 15 01:56 PM, Dick Van den Brink wrote:
> I like the idea of json config files but how to handle cases where a element can
> occur multiple times? With only one element, it would generate an object, but
> with multiple elements it would change into an array. This might make the code
> which reads the config a bit more difficult/error prone because it needs to check
> the type everytime.
> What do you guys think? Or is this a non-issue? Btw, I took a part of a plugin.xml
> as an example.
> Xml:
> <engines>
> <engine name="cordova-android" version=">=3.2.0" />
> <engine name="cordova-ios" version=">=3.0.0" /> </engines> Jason (array
> because engine element is found multiple times):
Good point,
It's more an issue with xml2js:
https://github.com/Leonidas-from-XIV/node-xml2js/blob/master/src/xml2js.coffee#L210
Could add an option for type conversion:
https://github.com/Leonidas-from-XIV/node-xml2js/blob/master/src/xml2js.coffee#L160
if (@options.jsType['array'][key])
obj[key] = [newValue]
Not perfect since all 'engine' tags would be an array but should be good enough for Cordova.
Or do the conversions in the 'cleanup', if( typeof json['engines']['engine'] != 'array') json['engines']['engine'] = [json['engines']['engine']];
https://github.com/jbondc/cordova-labs/blob/master/cordova-lib/config.ts#L52
Looks fixable either way,
J
Re: XML Namespaces
Posted by Marcel Kinard <cm...@gmail.com>.
I wouldn't expect you'd need an exact 1:1 mapping of xml elements to json objects. The json type may be able to collapse some of that. In the case of multiple repeating elements, how about something like this? (There is no "engine" because "engines" is an array. Assuming <engines> doesn't contain anything other than <engine>.)
{
"engines": [
{ "version": ">=3.2.0",
"name": "cordova-android"
},
{ "version": ">=3.0.0",
"name": "cordova-ios"
}
]
}
On Feb 15, 2014, at 1:56 PM, Dick Van den Brink <d_...@outlook.com> wrote:
> I like the idea of json config files but how to handle cases where a element can occur multiple times? With only one element, it would generate an object, but with multiple elements it would change into an array. This might make the code which reads the config a bit more difficult/error prone because it needs to check the type everytime.
> What do you guys think? Or is this a non-issue? Btw, I took a part of a plugin.xml as an example.
> Xml:
> <engines>
> <engine name="cordova-android" version=">=3.2.0" />
> <engine name="cordova-ios" version=">=3.0.0" />
> </engines>
> Jason (array because engine element is found multiple times):
> {
> "engines": {
> "engine": [
> {
> "-version": ">=3.2.0",
> "-name": "cordova-android"
> },
> {
> "-version": ">=3.0.0",
> "-name": "cordova-ios"
> }
> ]
> }
> }
>
> Or json with only one engine in the xml (so an object)
> "engine": {
> "-version": ">=3.2.0",
> "-name": "cordova-android"
> }
RE: XML Namespaces
Posted by Dick Van den Brink <d_...@outlook.com>.
I like the idea of json config files but how to handle cases where a element can occur multiple times? With only one element, it would generate an object, but with multiple elements it would change into an array. This might make the code which reads the config a bit more difficult/error prone because it needs to check the type everytime.
What do you guys think? Or is this a non-issue? Btw, I took a part of a plugin.xml as an example.
Xml:
<engines>
<engine name="cordova-android" version=">=3.2.0" />
<engine name="cordova-ios" version=">=3.0.0" />
</engines>
Jason (array because engine element is found multiple times):
{
"engines": {
"engine": [
{
"-version": ">=3.2.0",
"-name": "cordova-android"
},
{
"-version": ">=3.0.0",
"-name": "cordova-ios"
}
]
}
}
Or json with only one engine in the xml (so an object)
"engine": {
"-version": ">=3.2.0",
"-name": "cordova-android"
}
----------------------------------------
> From: jbondc@gdesolutions.com
> To: dev@cordova.apache.org
> Subject: RE: XML Namespaces
> Date: Sat, 15 Feb 2014 18:34:46 +0000
>
> On Fri Feb 14 02:30 PM, Marcel Kinard wrote:
>>
>> On Feb 13, 2014, at 10:04 AM, Jonathan Bond-Caron
>> <jb...@gdesolutions.com> wrote:
>>
>>> IBM most likely would prefer XML for the XSD & tooling...
>>
>> Not necessarily. Schema validation is nice, but XML for the sake of XML doesn't
>> make sense. What makes more sense is following standards where reasonably
>> possible. But if the widget spec is deprecated and we are making a conscious
>> decision to abandon it, then the leaning for XML goes away. Given the audience
>> of web devs, and the use of json config in other places, my preference would be
>> for json config.
>
> Great to have your opinion, my guesswork was that for a plugman based project on android for example, xml would be preferred.
>
>>
>>> Note about xml vs. json config, Cordova could support both.
>>
>> Cordova could, but that seems to me like overkill. If someone really wants xml,
>> how about providing an xslt that translates the xml to json, so they can author in
>> xml and Cordova could read json. But even that sounds like overkill too.
>
> It turns out there's a great node lib called 'xml2js', the code to do this is pretty simple:
> https://github.com/jbondc/cordova-labs/blob/master/cordova-lib/test.js
>
> https://github.com/jbondc/cordova-labs/blob/master/cordova-lib/config.ts
> https://github.com/jbondc/cordova-labs/blob/master/cordova-lib/config.js
>
> So the idea here is:
> - config.xml, config.json
> - plugin.xml, plugin.json
>
> Would both be supported, with json being looked for first.
>
RE: XML Namespaces
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Mon Feb 17 11:07 AM, Marcel Kinard wrote:
> Just curious, what drives your preference for XML over json?
>
It fits more naturally with some 'native' tools (e.g. android & windows 8). IDE's have better support for it.
If you're developing only with css,js,html -> json makes more sense
If you're developing using native tools (plugman flow) -> xml makes more sense
Exception is probably firefoxos, json all the way.
Re: XML Namespaces
Posted by Marcel Kinard <cm...@gmail.com>.
Just curious, what drives your preference for XML over json?
On Feb 17, 2014, at 10:55 AM, Jonathan Bond-Caron <jb...@gdesolutions.com> wrote:
> On Mon Feb 17 10:41 AM, Marcel Kinard wrote:
>> Would the intention be to eventually deprecate the xml after a "seamless"
>> transition period, or to keep the xml around for the foreseeable future?
>
> That's a good question... personally I still prefer XML over json. I would say keep the xml around for the foreseeable future,
>
> If nobody uses it, drop it eventually.
>
>
RE: XML Namespaces
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Mon Feb 17 10:41 AM, Marcel Kinard wrote:
>
> On Feb 15, 2014, at 1:34 PM, Jonathan Bond-Caron
> <jb...@gdesolutions.com> wrote:
>
> > So the idea here is:
> > - config.xml, config.json
> > - plugin.xml, plugin.json
> >
> > Would both be supported, with json being looked for first.
>
> Would the intention be to eventually deprecate the xml after a "seamless"
> transition period, or to keep the xml around for the foreseeable future?
That's a good question... personally I still prefer XML over json. I would say keep the xml around for the foreseeable future,
If nobody uses it, drop it eventually.
Re: XML Namespaces
Posted by Marcel Kinard <cm...@gmail.com>.
On Feb 15, 2014, at 1:34 PM, Jonathan Bond-Caron <jb...@gdesolutions.com> wrote:
> So the idea here is:
> - config.xml, config.json
> - plugin.xml, plugin.json
>
> Would both be supported, with json being looked for first.
Would the intention be to eventually deprecate the xml after a "seamless" transition period, or to keep the xml around for the foreseeable future? My thought would be to eventually be all js, with or without a transition period.
RE: XML Namespaces
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Fri Feb 14 02:30 PM, Marcel Kinard wrote:
>
> On Feb 13, 2014, at 10:04 AM, Jonathan Bond-Caron
> <jb...@gdesolutions.com> wrote:
>
> > IBM most likely would prefer XML for the XSD & tooling...
>
> Not necessarily. Schema validation is nice, but XML for the sake of XML doesn't
> make sense. What makes more sense is following standards where reasonably
> possible. But if the widget spec is deprecated and we are making a conscious
> decision to abandon it, then the leaning for XML goes away. Given the audience
> of web devs, and the use of json config in other places, my preference would be
> for json config.
Great to have your opinion, my guesswork was that for a plugman based project on android for example, xml would be preferred.
>
> > Note about xml vs. json config, Cordova could support both.
>
> Cordova could, but that seems to me like overkill. If someone really wants xml,
> how about providing an xslt that translates the xml to json, so they can author in
> xml and Cordova could read json. But even that sounds like overkill too.
It turns out there's a great node lib called 'xml2js', the code to do this is pretty simple:
https://github.com/jbondc/cordova-labs/blob/master/cordova-lib/test.js
https://github.com/jbondc/cordova-labs/blob/master/cordova-lib/config.ts
https://github.com/jbondc/cordova-labs/blob/master/cordova-lib/config.js
So the idea here is:
- config.xml, config.json
- plugin.xml, plugin.json
Would both be supported, with json being looked for first.
Re: XML Namespaces
Posted by Marcel Kinard <cm...@gmail.com>.
On Feb 13, 2014, at 10:04 AM, Jonathan Bond-Caron <jb...@gdesolutions.com> wrote:
> IBM most likely would prefer XML for the XSD & tooling…
Not necessarily. Schema validation is nice, but XML for the sake of XML doesn't make sense. What makes more sense is following standards where reasonably possible. But if the widget spec is deprecated and we are making a conscious decision to abandon it, then the leaning for XML goes away. Given the audience of web devs, and the use of json config in other places, my preference would be for json config. However, getting there in a way that is not disruptive to app devs and their existing apps is really important.
> Note about xml vs. json config, Cordova could support both.
Cordova could, but that seems to me like overkill. If someone really wants xml, how about providing an xslt that translates the xml to json, so they can author in xml and Cordova could read json. But even that sounds like overkill too.
But if the attraction of xml is schema validation, then perhaps that could be taken care of with http://json-schema.org/
Re: XML Namespaces
Posted by Brian LeRoux <b...@brian.io>.
Completely w/ Braden here. Lets stay the course on the big issues and save
this yak for a discreet initiative.
On Thu, Feb 13, 2014 at 8:35 AM, Andrew Grieve <ag...@chromium.org> wrote:
> On Thu, Feb 13, 2014 at 10:49 AM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > First, a brief point: We do *not* follow the widget spec, not anymore. We
> > were close, a long time ago, but we've added multiple Cordova-specific or
> > Phonegap-specific things and some slight tweaks to the meaning of some
> tags
> > and attributes. Since the widget spec is officially deprecated, I argue
> > that we can now stop caring about following the spec, and just decide
> what
> > configuration makes sense for Cordova.
> >
> While we don't currently follow it *semantically*, I think that we do
> follow it syntactically. This means XSD validation currently passes.
>
>
>
> >
> > Looking over Jonathan's "rough work" page, I generally like what I'm
> > seeing, except for the persistent question of what we're gaining with all
> > these changes. Like the JSON config files idea, I'd be happy if we were
> > already in that world. But the transition is sufficiently painful that
> > switching doesn't feel worth it; we don't gain enough to justify the
> pain.
> >
> > However! That only applies to the configuration file reshuffling. If we
> > really can refactor Plugman's flows to have reversible transactions, that
> > would definitely make me happy. But I don't think we should conflate the
> > config changes and that refactoring - they're independent. We would need
> to
> > expand the metadata tracked by plugman, of course, but that's not the
> same
> > as moving all the configuration.
> >
> > Braden
> >
> >
> > On Thu, Feb 13, 2014 at 10:04 AM, Jonathan Bond-Caron <
> > jbondc@gdesolutions.com> wrote:
> >
> > > On Thu Feb 13 09:37 AM, Andrew Grieve wrote:
> > > > Jonathan - I'm a fan of your "rough work" :)
> > > >
> > >
> > > Thanks, lots of credit to Braden & Mark around the plugman 'project'
> idea
> > >
> > > Note about xml vs. json config, Cordova could support both. Upstream
> > > distributions could choose to focus on config as XML, json or both.
> > > IBM most likely would prefer XML for the XSD & tooling, Adobe could do
> > XML
> > > for enterprise... json for web devs, ...?
> > >
> > > Don't think there's a silver bullet there.
> > >
> > > > Reason I'd want to use <cdv:icon> instead of <icon> for now, is to
> > > minimize the
> > > > number of "cdv:"s that appear. If you namespace the element, you
> don't
> > > need to
> > > > namespace the attributes. It also makes <cdv:icon> and
> > <cdv:splashscreen>
> > > > more similar.
> > >
> > > Makes sense, the work on cdv:icon could be pushed into the 4.0 config
> > > (with no namespace).
> > >
> > >
> >
>
Re: XML Namespaces
Posted by Andrew Grieve <ag...@chromium.org>.
On Thu, Feb 13, 2014 at 10:49 AM, Braden Shepherdson <br...@chromium.org>wrote:
> First, a brief point: We do *not* follow the widget spec, not anymore. We
> were close, a long time ago, but we've added multiple Cordova-specific or
> Phonegap-specific things and some slight tweaks to the meaning of some tags
> and attributes. Since the widget spec is officially deprecated, I argue
> that we can now stop caring about following the spec, and just decide what
> configuration makes sense for Cordova.
>
While we don't currently follow it *semantically*, I think that we do
follow it syntactically. This means XSD validation currently passes.
>
> Looking over Jonathan's "rough work" page, I generally like what I'm
> seeing, except for the persistent question of what we're gaining with all
> these changes. Like the JSON config files idea, I'd be happy if we were
> already in that world. But the transition is sufficiently painful that
> switching doesn't feel worth it; we don't gain enough to justify the pain.
>
> However! That only applies to the configuration file reshuffling. If we
> really can refactor Plugman's flows to have reversible transactions, that
> would definitely make me happy. But I don't think we should conflate the
> config changes and that refactoring - they're independent. We would need to
> expand the metadata tracked by plugman, of course, but that's not the same
> as moving all the configuration.
>
> Braden
>
>
> On Thu, Feb 13, 2014 at 10:04 AM, Jonathan Bond-Caron <
> jbondc@gdesolutions.com> wrote:
>
> > On Thu Feb 13 09:37 AM, Andrew Grieve wrote:
> > > Jonathan - I'm a fan of your "rough work" :)
> > >
> >
> > Thanks, lots of credit to Braden & Mark around the plugman 'project' idea
> >
> > Note about xml vs. json config, Cordova could support both. Upstream
> > distributions could choose to focus on config as XML, json or both.
> > IBM most likely would prefer XML for the XSD & tooling, Adobe could do
> XML
> > for enterprise... json for web devs, ...?
> >
> > Don't think there's a silver bullet there.
> >
> > > Reason I'd want to use <cdv:icon> instead of <icon> for now, is to
> > minimize the
> > > number of "cdv:"s that appear. If you namespace the element, you don't
> > need to
> > > namespace the attributes. It also makes <cdv:icon> and
> <cdv:splashscreen>
> > > more similar.
> >
> > Makes sense, the work on cdv:icon could be pushed into the 4.0 config
> > (with no namespace).
> >
> >
>
Re: XML Namespaces
Posted by Brian LeRoux <b...@brian.io>.
agreed widget is dead tho other specs are emergent solving the same
problems:
- mozilla fxos apps manifest.webapp
- chrome packaged apps manifest.json
- sys apps at the w3c is...discussing this
so I'm not sure if our efforts are best spent solving the problem w/ a new
format though that would be consistent w/ XKCD https://xkcd.com/927/
On Fri, Feb 14, 2014 at 7:55 AM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:
> On Thu Feb 13 10:49 AM, Braden Shepherdson wrote:
> >
> > except for the persistent question of what we're gaining with all these
> changes.
> > Like the JSON config files idea, I'd be happy if we were already in that
> world. But
> > the transition is sufficiently painful that switching doesn't feel worth
> it; we don't
> > gain enough to justify the pain.
> >
> > However! That only applies to the configuration file reshuffling. If we
> really can
> > refactor Plugman's flows to have reversible transactions, that would
> definitely
> > make me happy. But I don't think we should conflate the config changes
> and that
> > refactoring - they're independent. We would need to expand the metadata
> > tracked by plugman, of course, but that's not the same as moving all the
> > configuration.
> >
>
> Agree that some plugman refactoring isn't related to config changes.
> But some work would involve converting plugin.xml --> project.json
> (installed metadata)
>
> I'd argue we gain a lot by doing this, there's so much IO going on to keep
> the installed plugin.xml files around and reading those files.
> In comparison to a single project.json, that's a big benefit.
>
> If there's going to be code written to map xml to json, it makes sense to
> work on 1-1 mapping of xml & json config files in 1 swoop.
>
> Added a section on preferences around xml or json:
> https://wiki.apache.org/cordova/config/cordova.xml
>
> Ultimately the bit I think is important is dropping the widget spec, it's
> counter-productive.
>
>
RE: XML Namespaces
Posted by "Wargo, John" <jo...@sap.com>.
So isn't Cordova 4.0 a good time to do this and switch to JSON config files? Everyone is going to have to update their projects and plugins anyway, right?
I agree that dropping the widget spec is a good idea since it seems to be really limiting us.
-----Original Message-----
From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
Sent: Friday, February 14, 2014 10:55 AM
To: dev@cordova.apache.org
Subject: RE: XML Namespaces
On Thu Feb 13 10:49 AM, Braden Shepherdson wrote:
>
> except for the persistent question of what we're gaining with all these changes.
> Like the JSON config files idea, I'd be happy if we were already in that world. But
> the transition is sufficiently painful that switching doesn't feel worth it; we don't
> gain enough to justify the pain.
>
> However! That only applies to the configuration file reshuffling. If we really can
> refactor Plugman's flows to have reversible transactions, that would definitely
> make me happy. But I don't think we should conflate the config changes and that
> refactoring - they're independent. We would need to expand the metadata
> tracked by plugman, of course, but that's not the same as moving all the
> configuration.
>
Agree that some plugman refactoring isn't related to config changes.
But some work would involve converting plugin.xml --> project.json (installed metadata)
I'd argue we gain a lot by doing this, there's so much IO going on to keep the installed plugin.xml files around and reading those files.
In comparison to a single project.json, that's a big benefit.
If there's going to be code written to map xml to json, it makes sense to work on 1-1 mapping of xml & json config files in 1 swoop.
Added a section on preferences around xml or json:
https://wiki.apache.org/cordova/config/cordova.xml
Ultimately the bit I think is important is dropping the widget spec, it's counter-productive.
RE: XML Namespaces
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Thu Feb 13 10:49 AM, Braden Shepherdson wrote:
>
> except for the persistent question of what we're gaining with all these changes.
> Like the JSON config files idea, I'd be happy if we were already in that world. But
> the transition is sufficiently painful that switching doesn't feel worth it; we don't
> gain enough to justify the pain.
>
> However! That only applies to the configuration file reshuffling. If we really can
> refactor Plugman's flows to have reversible transactions, that would definitely
> make me happy. But I don't think we should conflate the config changes and that
> refactoring - they're independent. We would need to expand the metadata
> tracked by plugman, of course, but that's not the same as moving all the
> configuration.
>
Agree that some plugman refactoring isn't related to config changes.
But some work would involve converting plugin.xml --> project.json (installed metadata)
I'd argue we gain a lot by doing this, there's so much IO going on to keep the installed plugin.xml files around and reading those files.
In comparison to a single project.json, that's a big benefit.
If there's going to be code written to map xml to json, it makes sense to work on 1-1 mapping of xml & json config files in 1 swoop.
Added a section on preferences around xml or json:
https://wiki.apache.org/cordova/config/cordova.xml
Ultimately the bit I think is important is dropping the widget spec, it's counter-productive.
Re: XML Namespaces
Posted by Braden Shepherdson <br...@chromium.org>.
First, a brief point: We do *not* follow the widget spec, not anymore. We
were close, a long time ago, but we've added multiple Cordova-specific or
Phonegap-specific things and some slight tweaks to the meaning of some tags
and attributes. Since the widget spec is officially deprecated, I argue
that we can now stop caring about following the spec, and just decide what
configuration makes sense for Cordova.
Looking over Jonathan's "rough work" page, I generally like what I'm
seeing, except for the persistent question of what we're gaining with all
these changes. Like the JSON config files idea, I'd be happy if we were
already in that world. But the transition is sufficiently painful that
switching doesn't feel worth it; we don't gain enough to justify the pain.
However! That only applies to the configuration file reshuffling. If we
really can refactor Plugman's flows to have reversible transactions, that
would definitely make me happy. But I don't think we should conflate the
config changes and that refactoring - they're independent. We would need to
expand the metadata tracked by plugman, of course, but that's not the same
as moving all the configuration.
Braden
On Thu, Feb 13, 2014 at 10:04 AM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:
> On Thu Feb 13 09:37 AM, Andrew Grieve wrote:
> > Jonathan - I'm a fan of your "rough work" :)
> >
>
> Thanks, lots of credit to Braden & Mark around the plugman 'project' idea
>
> Note about xml vs. json config, Cordova could support both. Upstream
> distributions could choose to focus on config as XML, json or both.
> IBM most likely would prefer XML for the XSD & tooling, Adobe could do XML
> for enterprise... json for web devs, ...?
>
> Don't think there's a silver bullet there.
>
> > Reason I'd want to use <cdv:icon> instead of <icon> for now, is to
> minimize the
> > number of "cdv:"s that appear. If you namespace the element, you don't
> need to
> > namespace the attributes. It also makes <cdv:icon> and <cdv:splashscreen>
> > more similar.
>
> Makes sense, the work on cdv:icon could be pushed into the 4.0 config
> (with no namespace).
>
>
RE: XML Namespaces
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Thu Feb 13 09:37 AM, Andrew Grieve wrote:
> Jonathan - I'm a fan of your "rough work" :)
>
Thanks, lots of credit to Braden & Mark around the plugman 'project' idea
Note about xml vs. json config, Cordova could support both. Upstream distributions could choose to focus on config as XML, json or both.
IBM most likely would prefer XML for the XSD & tooling, Adobe could do XML for enterprise... json for web devs, ...?
Don't think there's a silver bullet there.
> Reason I'd want to use <cdv:icon> instead of <icon> for now, is to minimize the
> number of "cdv:"s that appear. If you namespace the element, you don't need to
> namespace the attributes. It also makes <cdv:icon> and <cdv:splashscreen>
> more similar.
Makes sense, the work on cdv:icon could be pushed into the 4.0 config (with no namespace).
Re: XML Namespaces
Posted by Andrew Grieve <ag...@chromium.org>.
Jonathan - I'm a fan of your "rough work" :)
Reason I'd want to use <cdv:icon> instead of <icon> for now, is to minimize
the number of "cdv:"s that appear. If you namespace the element, you don't
need to namespace the attributes. It also makes <cdv:icon> and
<cdv:splashscreen> more similar.
On Thu, Feb 13, 2014 at 8:13 AM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:
> On Wed Feb 12 05:00 PM, Andrew Grieve wrote:
> > So... I'd like to:
> > A: Remove xmlns="http://www.w3.org/ns/widgets" from our config.xml
> > template
> > B: Change xmlns:cdv="http://cordova.apache.org/ns/1.0" -> xmlns="
> > http://cordova.apache.org/ns/1.0"
> > C: Revert the commit that enforces the namespace to exist.
> >
> > This will allow us to add new tags & attributes to cordova.xml without
> > "violating"
> > XML namespace rules.
> >
> > Does anyone hate this idea?
>
> +1 for dropping widget spec in 4.0
>
> Issue with the widget spec is it doesn't take into account multiple
> platforms, or possibly different runtimes.
> A 'cordova app' is more similar to a plugin.xml (needs to be ported to
> multiple platforms).
>
> Some rough work here:
> https://wiki.apache.org/cordova/config/cordova.xml
>
> Using the widget spec as-is looks like a lowest-hanging fruit experience
> on multiple platforms.
>
> You need lots of xmlns:cdv, xmlns:gap, ... stuff to bridge the gap.
>
> Short term (3.x):
> -1 to A,B,C
> - add xmlns:cdv for custom icons, ...?
>
> Long term (4.x)
> - New cordova config file
> - Provide migration path of cordova 3.x project -> 4.x
>
>
RE: XML Namespaces
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Wed Feb 12 05:00 PM, Andrew Grieve wrote:
> So... I'd like to:
> A: Remove xmlns="http://www.w3.org/ns/widgets" from our config.xml
> template
> B: Change xmlns:cdv="http://cordova.apache.org/ns/1.0" -> xmlns="
> http://cordova.apache.org/ns/1.0"
> C: Revert the commit that enforces the namespace to exist.
>
> This will allow us to add new tags & attributes to cordova.xml without
> "violating"
> XML namespace rules.
>
> Does anyone hate this idea?
+1 for dropping widget spec in 4.0
Issue with the widget spec is it doesn't take into account multiple platforms, or possibly different runtimes.
A 'cordova app' is more similar to a plugin.xml (needs to be ported to multiple platforms).
Some rough work here:
https://wiki.apache.org/cordova/config/cordova.xml
Using the widget spec as-is looks like a lowest-hanging fruit experience on multiple platforms.
You need lots of xmlns:cdv, xmlns:gap, ... stuff to bridge the gap.
Short term (3.x):
-1 to A,B,C
- add xmlns:cdv for custom icons, ...?
Long term (4.x)
- New cordova config file
- Provide migration path of cordova 3.x project -> 4.x