[
Lists Home |
Date Index |
Thread Index
]
- From: Toby Speight <tms@ansa.co.uk>
- To: "XML developers' list" <xml-dev@ic.ac.uk>
- Date: 05 Jun 1998 10:52:53 +0100
John> John Cowan <URL:mailto:cowan@locke.ccil.org>
=> In article <3576FB58.39B139D4@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 &int-entity; and refer to
John> "&ext-entity;""/>
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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|
