Hi,
We would be
interested in using a different file extension than .xml for XForms documents
(OPS XForms examples all have a .xml extension). Although the specification, to
my knowledge, does not enforce any particular file extension, I was wondering if
you had a recommendation for what could be a best practice (the same way most
people and applications understand .wsdl files to be WSDL documents).
Let me suggest
".xform" .
We could use this in
our company as an internal best practice but I would be happier if this could be
a shared practice more widely used by XForms users beyond our company. Using a
specific file extensions would make it much easier to open XForms files with
specific editing properties in many editors.
Any idea/suggestion
would be much appreciated.
Thanks,
JAG
-- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
By the
standard Xforms must be used in a container language. XHTML is most
commonly used, but so is XSL, and XFDL. That kind of negates the need for
an .xform extension, but I am sure you could use it if you
want
-- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
In reply to this post by Jacques-Alexandre Gerber
Sure, but there is still a difference between a,
say, XHTML file with xforms extensions as opposed to without (for instance,
one can be most likely well rendered in a web browser whereas the latter will
most likely not look very nice)... The .xform extension could represent a
container language file with XForms control, I guess? In practice, you may
appreciate to launch different editors for XHTML, XSL and XForms files, which is
what a different extension would allow you to do.
JAG From: Richard Braman [mailto:[hidden email]] Sent: Tuesday, February 21, 2006 8:53 AM To: [hidden email] Subject: RE: [ops-users] XForm file extension By the
standard Xforms must be used in a container language. XHTML is most
commonly used, but so is XSL, and XFDL. That kind of negates the need for
an .xform extension, but I am sure you could use it if you
want
-- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Administrator
|
When you start having mixed content, you have a problem when it comes to
select one specific extension. What do you do if your document contains XHTML, XForms, SVG, and MathML? It may simply make more sense to use the host language extension. Note that in OPS we use .xhtml for static XHTML+XForms files, and .xsl for XSLT templates whether they contain XHTML and/or XForms or not. But we do *not* typically use .xml. If you see an XHTML+XForms file with a .xml extension, it's probably a candidate for renaming. Also, it is important to note that OPS does not care about file extensions, but only about file content. But since there is no standard practice anyway, if .xforms works for you, I would just say to go ahead and use that :-) -Erik Jacques-Alexandre Gerber wrote: > Sure, but there is still a difference between a, say, XHTML file with > xforms extensions as opposed to without (for instance, one can be most > likely well rendered in a web browser whereas the latter will most > likely not look very nice)... The .xform extension could represent a > container language file with XForms control, I guess? In practice, you > may appreciate to launch different editors for XHTML, XSL and XForms > files, which is what a different extension would allow you to do. > > JAG > > ------------------------------------------------------------------------ > *From:* Richard Braman [mailto:[hidden email]] > *Sent:* Tuesday, February 21, 2006 8:53 AM > *To:* [hidden email] > *Subject:* RE: [ops-users] XForm file extension > > By the standard Xforms must be used in a container language. XHTML is > most commonly used, but so is XSL, and XFDL. That kind of negates the > need for an .xform extension, but I am sure you could use it if you want > > -----Original Message----- > *From:* Jacques-Alexandre Gerber [mailto:[hidden email]] > *Sent:* Tuesday, February 21, 2006 12:01 PM > *To:* [hidden email] > *Subject:* [ops-users] XForm file extension > > Hi, > > We would be interested in using a different file extension than .xml > for XForms documents (OPS XForms examples all have a .xml > extension). Although the specification, to my knowledge, does not > enforce any particular file extension, I was wondering if you had a > recommendation for what could be a best practice (the same way most > people and applications understand .wsdl files to be WSDL documents). > > Let me suggest ".xform" . > > We could use this in our company as an internal best practice but I > would be happier if this could be a shared practice more widely used > by XForms users beyond our company. Using a specific file extensions > would make it much easier to open XForms files with specific editing > properties in many editors. > > Any idea/suggestion would be much appreciated. > > Thanks, > > JAG > > > ------------------------------------------------------------------------ > > > -- > You receive this message as a subscriber of the [hidden email] mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Hi,
if I may comment, it seems to me you are largely talking about two different things. JAG is concerned with editing the file, what, and how, application will respond to a request to open a file for editing. Erik is focused more on the publishing process, how a browser or similar application might anticipate what to do with a file it opens. Perhaps JAG, you could use one extension on your development system, and then when you release your files to a live server have a process (ant?) that can rename the files and their references to something that works for beyond the development world. hth Colin On Feb 21, 2006, at 3:17 PM, Erik Bruchez wrote: > When you start having mixed content, you have a problem when it comes > to select one specific extension. What do you do if your document > contains XHTML, XForms, SVG, and MathML? It may simply make more sense > to use the host language extension. > > Note that in OPS we use .xhtml for static XHTML+XForms files, and .xsl > for XSLT templates whether they contain XHTML and/or XForms or not. > But we do *not* typically use .xml. If you see an XHTML+XForms file > with a .xml extension, it's probably a candidate for renaming. > > Also, it is important to note that OPS does not care about file > extensions, but only about file content. > > But since there is no standard practice anyway, if .xforms works for > you, I would just say to go ahead and use that :-) > > -Erik > > > Jacques-Alexandre Gerber wrote: >> Sure, but there is still a difference between a, say, XHTML file with >> xforms extensions as opposed to without (for instance, one can be >> most likely well rendered in a web browser whereas the latter will >> most likely not look very nice)... The .xform extension could >> represent a container language file with XForms control, I guess? In >> practice, you may appreciate to launch different editors for XHTML, >> XSL and XForms files, which is what a different extension would allow >> you to do. -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
In reply to this post by Jacques-Alexandre Gerber
Thanks for your feedback. This is much appreciated. I think we'll use
*.xform for XHTML+Xforms, which cover most of our needs and would allow us to indeed recognize what editor to use with such files. This solves the editing problem and does not break anything at runtime since OPS does not care about the extension. Cheers, JAG -----Original Message----- From: Colin O'Brien [mailto:[hidden email]] Sent: Tuesday, February 21, 2006 12:43 PM To: [hidden email] Subject: Re: [ops-users] XForm file extension Hi, if I may comment, it seems to me you are largely talking about two different things. JAG is concerned with editing the file, what, and how, application will respond to a request to open a file for editing. Erik is focused more on the publishing process, how a browser or similar application might anticipate what to do with a file it opens. Perhaps JAG, you could use one extension on your development system, and then when you release your files to a live server have a process (ant?) that can rename the files and their references to something that works for beyond the development world. hth Colin On Feb 21, 2006, at 3:17 PM, Erik Bruchez wrote: > When you start having mixed content, you have a problem when it comes > to select one specific extension. What do you do if your document > contains XHTML, XForms, SVG, and MathML? It may simply make more sense > to use the host language extension. > > Note that in OPS we use .xhtml for static XHTML+XForms files, and .xsl > for XSLT templates whether they contain XHTML and/or XForms or not. > But we do *not* typically use .xml. If you see an XHTML+XForms file > with a .xml extension, it's probably a candidate for renaming. > > Also, it is important to note that OPS does not care about file > extensions, but only about file content. > > But since there is no standard practice anyway, if .xforms works for > you, I would just say to go ahead and use that :-) > > -Erik > > > Jacques-Alexandre Gerber wrote: >> Sure, but there is still a difference between a, say, XHTML file with >> xforms extensions as opposed to without (for instance, one can be >> most likely well rendered in a web browser whereas the latter will >> most likely not look very nice)... The .xform extension could >> represent a container language file with XForms control, I guess? In >> practice, you may appreciate to launch different editors for XHTML, >> XSL and XForms files, which is what a different extension would allow >> you to do. -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
In reply to this post by Jacques-Alexandre Gerber
I'd propose view on this also following way:
lets consider some different files with extention *.xform, but one contains XHTML, another - XFDL, still another - XSL. If all those files were not xml - than we could talk about different hosting languages. Naming them all with the same *.xform extension would "override" the hosting language contracts. Though in our case all these docs are xml. We may say that files containing xForms comprise a subset or restriction of all xml files set. What *.xform does is marks that subset to be identified by appropriate tools. Just the same thing as *.wsdl or *.xsl, or *.xsd, or even *.xhtml do: you may parse and edit them as pure xml, or use the specific tools for web-services, or xml translations. -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Free forum by Nabble | Edit this page |