[
Lists Home |
Date Index |
Thread Index
]
- From: Peter Newcomb <peter@techno.com>
- To: xml-dev@ic.ac.uk
- Date: Thu, 10 Apr 1997 12:09:12 -0400
> From: David Megginson <dmeggins@uottawa.ca>
>
> Peter Murray-Rust writes:
>
> > > The one short-coming is that XML does not support data-attributes, so
> > > it will not be possible to customise the AF support -- you'll have to
> > > stick with the defaults.
> >
> > This sounds reasonable for a first step :-)
>
> Perhaps -- some of the configuration is quite important, however (do
> you want to provide a bridge element for the targets of IDREFs, for
> example?).
There are a number of architecture support attributes, all of
which appear as data attributes of the architecture notation (the
notation pointed to by the ArcBase PI). Some of these attributes are
critical (i.e. needed 90% of the time), and one of them is required.
They are used to specify:
- the name of the architectural form attribute, used to identify the
architectural form to which an element conforms (default: same as
architecture notation name)
- the name of the architectural attribute renamer attribute, used to
resolve attribute name conflicts between multiple architectures
(default: no renaming)
- the name of the architecture suppressor attribute, used to control
the recognition of architectural forms from this architecture within
the content of an element (default: no suppression)
- the name of the architecture ignore data attribute, used to control
whether the data content an element is to be considered part of the
architectural instance (default: data is included or ignored
according to the architecture's meta-DTD)
- the name of the architecture document element form, to which the
document element must conform (default: same as architecture
notation name)
- the name of the meta-DTD entity (REQUIRED for validation)
- a list of quantity set variations for the architecture (default:
same as document)
- the default notation form for data entities (the bridge data
form) (default: data entities are not necessarily propagated to the
architectural document instance, and therefore cannot be used to
satisfy ENTITY architectural attributes)
- the default element form for elements with IDs (the bridge element
form) (default: element with IDs are not necessarily propagated to
the architectural document instance, and therefore cannot be used to
satisfy IDREF architectural attributes)
- whether or not to automatically map element types to element forms
of the same name (default: perform automatic mapping)
- the names of parameter entities to give the replacement text
"INCLUDE", used to identify the facilities of the architecture
required by the document (default: use only non-optional facilities)
- other architecture-specific options (e.g., in HyTime, the maximum
resolution required for finite coordinate spaces)
I would very much like to be able to use the SGML architecture
mechanism with XML, but XML's lack of data attributes makes it
impossible to do so, except in the simplest of cases. (And even in
those cases we cannot prove architectural validity for lack of a
meta-DTD entity name.) Either we need data attributes in XML, or a
different architecture binding mechanism needs to be devised. My
personal opinion is that the former would be easier, and more
generally useful, but I have to admit to a tendency to the more
general and therefore less easily implementable.
-peter
--
Peter Newcomb TechnoTeacher, Inc.
233 Spruce Avenue P.O. Box 23795
Rochester, NY 14611-4041 USA Rochester, New York 14692-3795 USA
+1 716 464 8696 (home) +1 716 464 8696 (direct)
+1 716 755 8698 (cell) +1 716 271 0796 (main)
+1 716 529 4304 (fax) +1 716 271 0129 (fax)
peter@petes-house.rochester.ny.us peter@techno.com
http://www.petes-house.rochester.ny.us http://www.techno.com
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)
|
