the whole question is in the title: is it possible to assign specific IDREF to a specific ID in DTD? I'm pretty sure it's not possible, but I just want to confirm it here :P
E.g. I have a client and worker elements with attributes of type ID, and "order" element with two attributes that should refer to the client making order and to a worker that receives the order. Simplified code from DTD:
<!ELEMENT worker (name, salary, employmDate)>
<!ATTLIST worker worker_id ID #REQUIRED subordinates IDREFS #IMPLIED>
<!ELEMENT client (name)>
<!ATTLIST client client_id ID #REQUIRED>
<!ELEMENT order (price, date)>
<!ATTLIST order cl_id IDREF #REQUIRED wrkr_id IDREF #REQUIRED>
Code works properly, there are no errors when validating, I have to use ID values for workers and clients and can add IDs of workers in "subordinates" argument for any worker.
However, I can write also client's ID as a subordinate or in case of an order element, I can use client's ID value for "wrkr_id" and worker's ID for "cl_id". Is there a way to constrain an IDREF to accept only IDs of one kind? Or maybe there's a way put constraints on ID attributes to make workers' IDs start with e.g. "w" and client's IDs start with e.g. "c" which would solve this problem at least partially?
Please, refrain from suggesting other sollutions than DTD. If it's possible, I want to do it in DTD as this is an assignment for my course and it has to be done in DTD if possible.
Thanks!
In SGML and XML DTDs, the pool of IDs against which IDREFs are validated is flat and undifferentiated -- so, no, there is no way to write a DTD to ensure that the IDREF on a 'wrkr_id' refers to the ID on a worker, that a 'client_id' refers to a client, and so on.
In practice, users of IDs and IDREFS (and of similar constructs in TeX and other document processing tools) frequently find it helpful to use conventions like beginning all client IDs with 'cl' and all worker IDs with 'wk'; it is then easy to check using XSLT, XQuery, or the document processing tool of your choice that all IDs and IDREFs have appropriate prefixes.
Moving that additional level of checking into the schema language, so that validation can provide firmer guarantees of correctness, is one of the motivations for the more complex structure of keys and keyrefs in XSD, and (generalizing a bit) for the assertions of Schematron and of XSD 1.1.