W3C home > Mailing lists > Public > www-forms@w3.org > May 2006

RE: Why no id attribute in common attributes?

From: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Tue, 23 May 2006 12:13:49 -0700
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF401DCB046@usa7061ms01.na.xerox.net>
To: "John Boyer" <boyerj@ca.ibm.com>
Cc: "Kelly Miller" <lightsolphoenix@gmail.com>, <www-forms@w3.org>
You have a good point that host languages that support xml:id and their
own id might as well support another id from XForms.
Good point about the id processing model being the same with XForms and
XHTML.
I have no objections then.
Leigh.

________________________________

From: John Boyer [mailto:boyerj@ca.ibm.com] 
Sent: Tuesday, May 23, 2006 12:08 PM
To: Klotz, Leigh
Cc: Klotz, Leigh; Kelly Miller; www-forms@w3.org
Subject: RE: Why no id attribute in common attributes?



Hi Leigh, 

> Does it seem that by declaring id in the common attributes, we can
still integrate with host languages that also define an attribute called
id and also allow applications that rely on xml:id to work? 

JB> Yes, we can still integrate with host languages that declare a
global attribute as in fact any host language that claims support for
xml:id is already doing that.  Putting id in the common attributes part
of the schema would cause it to show up in the Per-Element-Type
partition whereas a host language would be declaring a global attribute
(if it were expected to work in the elements of XForms, that is).   All
such host languages already now have to deal with the potential conflict
between their declared global id attribute and the possibility of having
xml:id.  The reality is that the problem is not with the host language
but rather the form author.  As long as they only put one actual
attribute of type ID on the element, it will work-- even if host
language elements are using a different attribute of type ID.   

> The sense we had when we pulled id out of common was that it couldn't
work; similar arguments have been used recently to remove @src from
help, hint, and alert. 

JB> @src was removed for a wholly different reason.  The @src in XHTML
is resolved at a well-defined moment, and this conflicted with when it
might have to be resolved by XForms.  The issue with ID is unrelated as
their is no disconnect where being an ID attribute means something
different based on whether it is coming from an unqualified attribute
versus a global attribute (be it from the host language or from XML
itself). 

Best regards, 
John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Klotz, Leigh" <Leigh.Klotz@xerox.com> 

05/23/2006 10:54 AM 

To
John Boyer/CanWest/IBM@IBMCA 
cc
"Kelly Miller" <lightsolphoenix@gmail.com>, <www-forms@w3.org>, "Klotz,
Leigh" <Leigh.Klotz@xerox.com> 
Subject
RE: Why no id attribute in common attributes?

	




John, 
I think the idea with xml:id was that XML application would eventually
switch to it, much like they currently use xml:lang. 
As you point out, it doesn't obviate the need to allow it in
application; it's just that when you do specify it, you would spell it
that way. 
  
I wholly agree with you that importing XForms into an application's
namespace, such as is proposed for XHTML2, is a good idea. 
But it seems to me that leaving @id in the host-language section is
consistent with this goal.   
  
If the host language chooses to require xhtml:id, then it will have to
be spelled that way, but if it uses non-namespaced id, then it would be
spelled that way. 
  
Does it seem that by declaring id in the common attributes, we can still
integrate with host languages that also define an attribute called id
and also allow applications that rely on xml:id to work? 
The sense we had when we pulled id out of common was that it couldn't
work; similar arguments have been used recently to remove @src from
help, hint, and alert. 
  
Leigh. 


________________________________

From: John Boyer [mailto:boyerj@ca.ibm.com] 
Sent: Tuesday, May 23, 2006 9:39 AM
To: Klotz, Leigh
Cc: Kelly Miller; www-forms@w3.org; www-forms-request@w3.org
Subject: RE: Why no id attribute in common attributes?


Hi Leigh, 

Since it is not the case that xml:id deprecated the use of ID type
attributes, the question arises: 

If an XML vocabulary describes an ID attribute and XML itself describes
an ID attribute, which one do you put? 

This is the same question as the one you asked below about xhtml:id
versus xforms:id.  And the answer is that 
it doesn't really matter.  XML does not say that you can't have two
*possible* attributes of type ID.  It only says 
that you can't have two *actual* attributes of type ID. 

This is part of why I believe that the argument against declaring an id
in common attributes holds no water. 

Moreover, the question of xhtml:id versus xforms:id is a bit of a
tangent because what I'd like to do is 
have the id attribute be in the Per-Element-Type partition, not the
Global Attribute partition.  This means 
one would write id as an unqualified attribute, not as one qualified by
a namespace prefix. 

This is the other part of why I believe there is no good argument
against declaring an id in XForms common attributes. 

Authors want to be able to write id="X" rather than xhtml:id="X".  In
particular, it is the desire to reduce namespace 
qualification that is causing us to want to import the XForms vocabulary
into the XHTML2 namespace.  Forcing 
XForms authors to namespace qualify their ID attributes works against
this goal. 

Best regards, 
John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer




"Klotz, Leigh" <Leigh.Klotz@xerox.com> 
Sent by: www-forms-request@w3.org 

05/19/2006 03:55 PM 



To
John Boyer/CanWest/IBM@IBMCA, "Kelly Miller" <lightsolphoenix@gmail.com>

cc
<www-forms@w3.org>, <www-forms-request@w3.org> 
Subject
RE: Why no id attribute in common attributes?


	





xml:id *came* from XForms.  You might recall it was proposed by Steven
Pemberton at the San Diego F2F Halloween 2000. 
 
   Steven Pemberton: Let's create a draft for xml:id.
  Leigh Klotz: We're all having trouble with it; let's all be authors.
  Steven Pemberton: OK. We cannot put DTDs in external instances in
XForms, so there is no way to declare ID attributes on them. 

    Resolution 2002-11-21.2:
<http://lists.w3.org/Archives/Member/w3c-forms/2002OctDec/att-0211/01-20
02nov01.html#resolution2>  We create a draft for xml:id to help ease
problems with XForms integration. 

The rationale for leaving it out is not flimsy; it has everything to do
with namespaces.   
If XHTML describes an id called xhtml:id and xforms describes and id
called xforms:id, and XML says you can't have two ID attributes on the
same element, which one do you put? 
 
Leigh. 


________________________________

From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of John Boyer
Sent: Friday, May 19, 2006 10:05 AM
To: Kelly Miller
Cc: www-forms@w3.org; www-forms-request@w3.org
Subject: Re: Why no id attribute in common attributes?


Hi Kelly, 

Not really. 
In fact, I've raised the issue again exactly because of the xml:id
recommendation. 

Fact is, I don't necessarily want to type xml:id all over the place, so
having an id available 
is highly desirable.   

As I recall, the rationale for leaving it out was kind of flimsy.  I
believe the thinking was that 
the host document format might want to be in control of the naming
convention for IDs 
throughout the document. 

I think xml:id breaks that. 

The other possibility was that the above might be needed to ensure that
our declaration 
of an id attribute didn't conflict with declarations needed by the host
language if they 
were trying to control ID-ness uniformly in some way.  However, this
seems to confuse 
the notion of having more than one possible ID attribute with actually
declaring more than 
one ID attribute, only the latter of which is non-valid. 

And again, xml:id itself provides the possibility but not the reality of
a second ID attribute. 

Finally, notwithstanding the problems, it still doesn't seem very
compelling compared to 
not having an id attribute automatically available in the content model,
esp. since we declare 
so many IDREFs in the schema. 

Cheers, 
John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer



Kelly Miller <lightsolphoenix@gmail.com> 
Sent by: www-forms-request@w3.org 

05/19/2006 04:52 AM 



To
John Boyer/CanWest/IBM@IBMCA 
cc
www-forms@w3.org 
Subject
Re: Why no id attribute in common attributes?




	







-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Does leaving this out have something to do with the xml:id
Recommendation?

John Boyer wrote:
| The XForms schema makes lots of attributes of type xsd:IDREF, but
| Common Attributes appears to be missing the following:
|
|     <xsd:attribute name="id" type="xsd:ID" use="optional"/>
|
| Rather than forcing every host language to add this attribute to the
| schema, an XForms 1.0 erratum should add this to the XForms schema.
|
| The argument that the host language may want to have its own uniform
| way of assigning identities does not seem to hold water, esp. given
| xml:id.
|
| John M. Boyer, Ph.D.
| Senior Product Architect/Research Scientist
| Co-Chair, W3C XForms Working Group
| Workplace, Portal and Collaboration Software
| IBM Victoria Software Lab
| E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/
|
| Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
|
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEbbGDvCLXx0V8XHQRAmb+AKCeubPK+1qNn3mB8bJOAnW8mJWTlACgqsox
4Ac1eawEzT7E+de5vANhX5w=
=RN2D
-----END PGP SIGNATURE-----
Received on Tuesday, 23 May 2006 19:15:28 GMT

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