OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: a:attributeType


Murata Makoto wrote:
> I think that the user should not be forced to use the XML
> Schema datatype library, which is buggy and complicated,
> only to use ID/IDREF/IDREFS.  Is it OK if an implementation
> implements only ID/IDREF/IDREFS (and possibly easy built-in
> datatypes and facets) and do not implement other complicated
> datatypes and facets?

This seems to be a rationale for using a:attributeType="ID" instead of <data
type="xsd:ID"/>.

We are not requiring them to implement XML Schema Part 2 but if they need
ID/IDREF/IDREFS, are we going to foist XSP2 on them just to get ID, etc.? I
don't think that's what we want, is it?

A gnawing question in my mind is what about NMTOKEN, NMTOKENS, ENTITY,
ENTITIES, and NOTATION? If someone implements XSP2 and they specify <data
type="xsd:NOTATION"/>, what are they required to get? Must an attribute of
this type be required to have the same behavior as specified in XML 1.0?
What could or should we do for about NMTOKEN, etc. when we specify
properties behavior for ID/IDREF/IDREFS? Is it a judgment call as to what is
important?

Couldn't we introduce a:attributeType as a common mechanism to trigger XML
1.0 attribute types, without requiring validation or any special processor
behavior except as required by the implementer?

If you think I am swinging an axe wildly through the air, you are right.

Mike



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC