Notations, subschemas, entities

[Toby Speight]

John> John Cowan <URL:mailto:cowan at locke.ccil.org>

=> In article <3576FB58.39B139D4 at locke.ccil.org>, John wrote:

John> Toby Speight wrote:

>> I can't remember (nor find easily in the spec) whether notations
>> must be declared before use.

John> There seems to be no such requirement.  The VC simply says:
John> "Values of this type [i.e., notation] must match one of the
John> notation names included in the declaration; all notation names
John> in the declaration must be declared."

Yes, that's all I could find.


John> Indeed, I'm thinking that XSchemas should have structure, ...

>> Sorry, you lost me with this paragraph. Can you illustrate it with an
>> example?

John> In other words:
John>
John> 	<DOCTYPE root="blah">
John> 	 <DOCTYPE>
John>            <ELEMENT id="blah"> ... </ELEMENT>
John> 	   <ELEMENT id="bazz"> ... </ELEMENT>
John> 	   <NOTATION id="foo"> ... </ELEMENT>
John> 	 </DOCTYPE>
John> 	 <DOCTYPE>
John> 	   <ELEMENT id="zim"> ... </ELEMENT>
John> 	   <DOCTYPE>
John> 	    <ENTITY ...> ... </ENTITY>
John> 	    <ENTITY ...> ... </ENTITY>
John> 	   <ELEMENT id="zam"> ... </ELEMENT>
John> 	 </DOCTYPE>
John> 	</DOCTYPE>

Ah, I see.  While it does mean there are many functionally-equivalent
XSchemas for a given DTD, I have no real objection to this (although
if I were creating reusable XSchema fragments, I'd stick the ELEMENT
etc. declarations in a separate file, and have my XSchema reference
them.  I'm not 100% convinced of the utility of importing a schema
that hasn't been designed for re-use.


John> My concern is that we will bloat the simple XSchema DTD with
John> elements for marking up fancy text.  If we were going to do
John> that, we'd need a subschema (see above!) that handled just the
John> bare bones of fancy text, ...

Yes, that's a danger.  I think we need to thrash out documentation
issues in a separate discussion.  Unfortunately, I may be unable to
see it through to the end, as I'm on holiday from 13th June until the
end of the month.


>> <!ELEMENT EXTERNAL-ENTITY (DOC?)>
>> <!ATTLIST EXTERNAL-ENTITY
>> %external;
>> notation CDATA #IMPLIED>
>> <!ELEMENT INTERNAL-ENTITY (DOC?)>
>> <!ATTLIST INTERNAL-ENTITY
>> value CDATA #REQUIRED>

John> Using an attribute value to hold the definition of an internal
John> entity involves processing out all markup characters (&, <, ',
John> "), thus:
John>
John> <!ENTITY yutz 'I use &int-entity; and refer to "&ext-entity;"'>
John>
John> would come out as
John>
John> <INTERNAL-ENTITY value="I use &amp;int-entity; and refer to
John> &quot;&amp;ext-entity;&quot;"/>
John>
John> whereas
John>
John> <INTERNAL-ENTITY><![CDATA[I use &int-entity; and refer to
John> "&ext-entity;"]]></INTERNAL-ENTITY>
John>
John> is far more readable and writable.
John>
John> The spec should say that the content of an ENTITY element should be
John> wrapped in a CDATA marked section.

"Should" might be wording it too strongly.  I agree with your point
here, but I think it's orthogonal to whether internal and external
entities should use the same element type.  I like the value-as-content
as you wrote it above, if EXTERNAL-ENTITY remains as I wrote.  The
reason I didn't put the value as content was due to my allowance for
DOC; we'd need

<!ELEMENT INTERNAL-ENTITY (DOC?, LITERAL)>
<!ELEMENT LITERAL (#PCDATA)>

to satisfy XML's restrictions on mixed content.

-- 


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)