W3C home > Mailing lists > Public > www-forms@w3.org > July 2008

Re: namespace question

From: Scott Shattuck <idearat@mindspring.com>
Date: Fri, 18 Jul 2008 17:45:06 -0600
Message-Id: <48FE7D34-2B95-4802-8BCA-41B8516EAFD8@mindspring.com>
To: www-forms@w3.org

My two cents, the bad idea is serializing content without preserving  
the namespace. The null namespace is a valid namespace, just as is any  
other namespace. So allowing it to be dropped is almost guaranteed to  
create bugs when the content so serialized is subsequently read back  
into a new document. Perhaps putting xf:instance in the mix is a bad  
example since there are clearly workaround and other semantics which  
are not commonly associated with how infoset merging might occur.


On Jul 18, 2008, at 3:12 PM, Erik Bruchez wrote:

>
>> This is, IMHO, a really bad idea.
>
> What is? What behavior do you suggest?
>
> One thing to consider is that xf:instance will then build a new  
> document from its child element. So it extracts the infoset and  
> build a new, completely separate document.
>
> Note that rather than using XInclude, you can use xf:instance/@src.  
> That will make sure you don't go through the extra steps of infoset  
> merging / extraction.
>
> -Erik
>
>> Here's a not-so-uncommon use case:
>>
>> Assume I have a the following content in file foo.xml:
>>
>> <employees>
>> 	<employee...>
>> 		....
>> 	</employee>
>> </employees>
>>
>> Now, assume further that I have the following XHTML document:
>>
>> <html xmlns="http://www.w3.org/1999/xhtml">
>>
>> <head>
>> 	<xf:model xmlns:xf="http://www.w3.org/2002/xforms">
>> 		<xf:instance>
>> 			<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"  
>> href="foo.xml"/>
>> 		</xf:instance>
>> 	</xf:model>
>> </head>
>>
>> <body>....</body>
>> </html>
>>
>> In this case, the burden of making sure that the <employees>  
>> element gets an 'xmlns=""' falls to the XInclude processor. Here's  
>> the relevant section from the XInclude specification, 2nd Ed.,  
>> regarding 'Infoset merging':
>>
>>
>> 4.5.4 Namespace Fixup
>>
>> The in-scope namespaces property ensures that namespace scope is  
>> preserved through inclusion. However, after inclusion, the  
>> namespace attributes property might not provide the full list of  
>> namespace declarations necessary to interpret qualified names in  
>> attribute or element content in the result. It is therefore not  
>> recommended that XInclude processors expose namespace attributes in  
>> the result. If this is unavoidable, the implementation may add  
>> attribute information items to the namespace attributes property in  
>> order to approximate the information conveyed by in-scope namespaces.
>>
>>
>> The behavior proposed here would force the XInclude processor to  
>> use the mechanism described after "If this is unavoidable..." and,  
>> given that the specification here says MAY not MUST, its not a  
>> required behavior for the XInclude processor. And this wouldn't be  
>> the only place where not explictly producing namespace information  
>> is dangerous.
>>
>> As the person who reported a bug in Mozilla's XML Serializer that  
>> was improperly serializing null namespaces (https://bugzilla.mozilla.org/show_bug.cgi?id=301260 
>>  - finally fixed in Mozilla 1.9 / FF 3.0), this whole thing smells  
>> really bad to me and violates Jon Postel's Robustness Principle (http://en.wikipedia.org/wiki/Robustness_Principle 
>> ).
>>
>> Cheers,
>>
>> - Bill
>>
>> On Jul 18, 2008, at 11:33 AM, Klotz, Leigh wrote:
>>
>>> Here's my take:  Omitting xmlns="" on the root element has another  
>>> advantage, in that it makes it easier for non-namespace-aware  
>>> services to accept the posted XML. The attribute submission/ 
>>> @includenamespaceprefixes was added to facilitate interoperation  
>>> with services such as those that use DTD validation.  Since  
>>> xmlns="" doesn't add anything to the party for namespace-aware  
>>> applications, and might startly DTD applications, leaving it off  
>>> seems a good plan.
>>> Leigh.
>>>
>>> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org]  
>>> On Behalf Of Nick_Van_den_Bleeken@inventivegroup.com
>>> Sent: Thursday, July 17, 2008 11:40 PM
>>> To: Aaron Reed
>>> Cc: www-forms@w3.org; www-forms-request@w3.org
>>> Subject: Re: namespace question
>>>
>>>
>>> Hi Aaron,
>>>
>>> When the root element of the instance has a default  namespace  
>>> declaration with the attribute value of the empty string  
>>> (xmlns=""), you may omit  this default namespace declaration on  
>>> the root element that is serialized (it is even preferable to do  
>>> so, but it is not an error to xmlns="" on the root element).
>>>
>>> See [1] for more information and more specific the text : "The  
>>> attribute value in a default namespace declaration MAY be empty.  
>>> This has the same effect, within the scope of the declaration, of  
>>> there being no default namespace."
>>>
>>> If you have any further questions please feel free to send an e- 
>>> mail to the list. And we will do our best to help you ;)
>>>
>>> Regards,
>>>
>>> Nick Van den Bleeken  -  Research & Development Manager
>>> Inventive Designers
>>> Phone: +32 - 3 - 8210170
>>> Fax: +32 - 3 - 8210171
>>> Email: Nick_Van_den_Bleeken@inventivegroup.com
>>>
>>> 1: http://www.w3.org/TR/REC-xml-names/#defaulting
>>>
>>> www-forms-request@w3.org wrote on 07/17/2008 06:47:03 PM:
>>>
>>> >
>>> > Hi Nick,
>>> >
>>> > Yep, we know it is a bug in Firefox that the root namespace from  
>>> the
>>> > host document is making into the submitted document as the default
>>> > namespace when the default namespace was given to be empty.  But  
>>> what
>>> > we'd like to know is whether a default empty namespace should be  
>>> placed
>>> > on the submitted document at all.  If the first default  
>>> namespace we see
>>> > is empty as we work our way up the tree, should we NOT output it  
>>> and
>>> > from then on ignore the default namespace or should we output it?
>>> >
>>> > Thanks,
>>> > --Aaron
>>> >
>>> > Nick_Van_den_Bleeken@inventivegroup.com wrote:
>>> > >
>>> > > Hi Swithun,
>>> > >
>>> > > Your problem is a bug in Firefox, the default namespace of the  
>>> submitted
>>> > > instance should be the empty one. You have correctly specified  
>>> this on
>>> > > your in-line instance.
>>> > >
>>> > > I searched the Firefox XForms bugzilla database and found a  
>>> bug report
>>> > > for this problem https://bugzilla.mozilla.org/show_bug.cgi?id=445285 
>>> .
>>> > > You probably want to vote on this bug report.
>>> > >
>>> > > Regards,
>>> > >
>>> > > Nick Van den Bleeken  -  Research & Development Manager
>>> > > Inventive Designers
>>> > > Phone: +32 - 3 - 8210170
>>> > > Fax: +32 - 3 - 8210171
>>> > > Email: Nick_Van_den_Bleeken@inventivegroup.com
>>> > >
>>> > > www-forms-request@w3.org wrote on 07/11/2008 03:23:10 PM:
>>> > >
>>> > >  >
>>> > >  > Hello
>>> > >  >
>>> > >  > I have a small puzzling problem. I have an XForms document  
>>> where the
>>> > >  > default namespace is declared as so:
>>> > >  >
>>> > >  > <html xmlns="
>>> > > <http://www.w3.org/1999/xhtml>http://www.w3.org/1999/xhtml" ...
>>> > >  >
>>> > >  > (with all the other namespaces there too)
>>> > >  >
>>> > >  > Then, in one of the instances, the default namespace is  
>>> declared as
>>> > > empty:
>>> > >  >
>>> > >  > <xf:instance id="text_instance">
>>> > >  >    <tei:TEI xmlns=""> ...
>>> > >  >
>>> > >  > But then, when this instance is submitted, it shows up as:
>>> > >  >
>>> > >  > <tei:TEI xmlns=" <http://www.w3.org/1999/xhtml>
>>> > > <http://www.w3.org/1999/xhtml>http://www.w3.org/1999/xhtml" ...
>>> > >  >
>>> > >  > I would like to get rid of this default namespace  
>>> declaration. I would
>>> > >  > rather not have to use a non-default namespace for the  
>>> XHTML elements.
>>> > >  > Shouldn't the xmlns="" inside the instance override the
>>> > > xmlns="http..." in
>>> > >  > the ancestor html element?
>>> > >  >
>>> > >  > Does anyone have any ideas? I'm using Firefox  
>>> (2.0.0.14/0.8.5). I can
>>> > > ask
>>> > >  > on the Mozilla XForms list if anyone thinks it is a  
>>> implementation
>>> > >  > specific problem.
>>> > >  >
>>> > >  > A copy of the form is here:
>>> > >  > <http://swithun.servebeer.com/namespace.xhtml>
>>> > > <http://swithun.servebeer.com/namespace.xhtml>http://
>>> > swithun.servebeer.com/namespace.xhtml
>>> > >  >
>>> > >  > Thanks.
>>> > >  >
>>> > >  > Swithun.
>>> > >  >
>>> > >  >
>>> > >  > --
>>> > >  > 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
>>> > >
>>> > >
>>> > > --
>>> > > This message has been scanned for viruses and
>>> > > dangerous content, and is believed to be clean.
>>> > > --
>>> > >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > 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
>>>
>>>
>>> -- 
>>> This message has been scanned for viruses and
>>> dangerous content, and is believed to be clean.
>>> -- 
>>>
>>
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>
>
Received on Friday, 18 July 2008 23:45:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:13 GMT