W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > May 2007

Label and ID stuff

From: Innovimax SARL <innovimax@gmail.com>
Date: Sat, 5 May 2007 13:51:23 +0200
Message-ID: <546c6c1c0705050451o5a6edfeeif450c3aa7b4b9f9f@mail.gmail.com>
To: "XProc WG" <public-xml-processing-model-wg@w3.org>


A.1.8 Label Elements

The Label Elements step labels each element with a unique xml:id
value. If the element already has an xml:id value, that value is
preserved. A user may specify the prefix and/or suffix options for
prefixing or suffixing the generated value of the xml:id attribute.
These prefixes or suffixes do not affect existing xml:id values.

If an existing xml:id value conflicts with a previously generated
value, the step fails.

<p:declare-step type="p:label-elements">
     <p:input port="source"/>
     <p:output port="result"/>
     <p:option name="prefix" required="no"/>
     <p:option name="suffix" required="no"/>

First, I was thinking that we could select trough an pattern
expression, which elements, I want to label (applying "*" if I really

Second, I don't really understand that limitation

<< If an existing xml:id value conflicts with a previously generated
value, the step fails. >>

Does it mean that if, I have done a dummy implementation of XProc
which generate concat($prefix, '0', $suffix), and that there is more
than two element to label, I am allowed by the spec to fail !!!

We should be clear on the Label component. At this stage, we can
output an INVALID document for multiple raison :

1) In the target model, may be xml:id is not allowed **on every
element** (without the proposed modificaiton)
2) Since ID validation in DTD and Schema is not scoped, we could
generate duplicate ID values in the document
3) We could throw an "One ID per Element Type" constraint


Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
RCS Paris 488.018.631
SARL au capital de 10.000 
Received on Saturday, 5 May 2007 11:51:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:42 UTC