Parsers preserve order of IDs in IDREFS ?

[Mark]

In a specification I'm designing, I'd like to specify that the order
of Names (IDs) in an attribute value of datatype IDREFS is
significant.

My question is if most real-world XML parsers preserve the order of
IDs in IDREFS? If most don't, then specifying the significance of
order is problematic.

(As far as I can tell, the XML 1.0 spec is silent on this topic.)

Thanks.

Mark

[Martin Honnen]

Mark wrote:

In a specification I'm designing, I'd like to specify that the order
of Names (IDs) in an attribute value of datatype IDREFS is
significant.

My question is if most real-world XML parsers preserve the order of
IDs in IDREFS?

If the attribute value is a sequence of white space separated IDs then I
don't see why any XML parser would change the order of that sequence
when passing the attribute value on to an application. I don't see why
parsers would touch attribute values at all (with some exception of
complicated values with entity references where a particular data model
(e.g. XPath) does not model such stuff).

--

Martin Honnen
http://JavaScript.FAQTs.com/

[Peter Flynn]

Mark wrote:

In a specification I'm designing, I'd like to specify that the order
of Names (IDs) in an attribute value of datatype IDREFS is
significant.
The order of ID values in an IDREFS attribute is not significant in
XML. The purpose of IDREFS is to allow the specification of a multi-
headed link between the element bearing that attribute and the separate
elements bearing the various IDs. It wasn't designed to allow order to
be expressed, although as you rightly ask below, once entered, the data
is not subsequently changed by a parser.

If the order is significant in your application, then the code to check
or enforce this significance must be written into your application. The
parser (validator) is only interested in checking that an ID value
exists elsewhere in the document for each IDREF[S] value given.
My question is if most real-world XML parsers preserve the order of
IDs in IDREFS?
IMHE yes, they leave them alone. I can't speak for unreal-world parsers :-)
If most don't, then specifying the significance of
order is problematic.
I'd be very interested to know why the order would be significant.
Are you at liberty to give more details? In applications I have seen
where the order of link processing *is* significant, other markup has
been used to express this (eg in TEI the <linkGrp> container).
(As far as I can tell, the XML 1.0 spec is silent on this topic.)

AFAIK it's never been an issue.

///Peter
--
XML FAQ: http://xml.silmaril.ie/

[Richard Tobin]

In article <42*************@individual.net>,
Peter Flynn <re*********@m.from.email.address> wrote:

The order of ID values in an IDREFS attribute is not significant in
XML.

The XML specification doesn't say anything explicit about this. But
what it requires parsers to pass to applications is the normalized
(string) value of the attribute, not a list of IDs. And the string
must be in the original order - all that is done to it is whitespace
normalization.

The XML Infoset is clear: the [references] property is an ordered
list, and reflects the order in the attribute.

-- Richard

[Mark]

Thanks also to Martin and Peter for replying to my basic inquiry.

Richard Tobin wrote:

Peter Flynn wrote:

The order of ID values in an IDREFS attribute is not significant in
XML.

The XML specification doesn't say anything explicit about this. But
what it requires parsers to pass to applications is the normalized
(string) value of the attribute, not a list of IDs. And the string
must be in the original order - all that is done to it is whitespace
normalization.
<slapping what="hand on head"/>

I should have remembered this from the XML spec! Thanks for reminding
me that parsers preserve attribute values (with white space
normalization as required) to send to the application. I'm clearly not
an expert on XML parsing, so I appreciate the feedback from those who
are.

The XML Infoset is clear: the [references] property is an ordered
list, and reflects the order in the attribute.

Thanks.

I'll also check out a different approach as suggested by Peter (e.g.,
the TEI <linkGrp>.)
On a related topic, I am confused about what XML 1.0 says about the
"space" between IDs in IDREF, and reconcile that with what is being
said on the Internet (which often says "white space".)

According to Section 3.3.1 of the XML spec, datatype IDREFS must
match the "Names" production. "Names" is defined in Section 2.3 [6]
as follows:

[6] Names ::= Name (#x20 Name)*

Notice this allows only one space character between "Name", not
white space (which can be any number of spaces, carriage returns,
line feeds, and tabs.)

So what am I missing here?

Thanks again.

[Richard Tobin]

In article <et********************************@4ax.com>,
Mark <ma**@nowhere.com> wrote:

According to Section 3.3.1 of the XML spec, datatype IDREFS must
match the "Names" production. "Names" is defined in Section 2.3 [6]
as follows:

[6] Names ::= Name (#x20 Name)*

Notice this allows only one space character between "Name", not
white space (which can be any number of spaces, carriage returns,
line feeds, and tabs.)

So what am I missing here?

Before the validity constraints, 3.3.1 says:

The validity constraints noted in the grammar are applied after the
attribute value has been normalized as described in 3.3.3
Attribute-Value Normalization.

(If it defined the constraint in terms of the un-normalized value, the
definition would have to deal with entity and character references, as
well as allowing all the kinds of white space.)

-- Richard

[Mark]

Richard Tobin

So what am I missing here?

Before the validity constraints, 3.3.1 says:

The validity constraints noted in the grammar are applied after the
attribute value has been normalized as described in 3.3.3
Attribute-Value Normalization.

(If it defined the constraint in terms of the un-normalized value, the
definition would have to deal with entity and character references, as
well as allowing all the kinds of white space.)

Thanks, Richard. That clarifies it. I did not read far enough back in
that section.