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-----