Re: DOCTYPE (was Re: Announcement: SAX 1998-01-12 Draft)
Peter Murray-Rust wrote: > Thanks. I wasn't aware of this. We need something like it. It does, > of > course, rely on building a significant registry for FPIs. As far as I > remember from previous discussions very FPIs are registered at > present, and > the mechanism is not widely known. If this mechanism is to become > popular > for XML - before the WWW gets swamped with untyped documents without > meaningful FPIs - there needs to be a lot of effort to publicise and > implement it. I think we need to add an architecture system-id attribute, which would let you provide a URL for the architecture definition document. I don't think that would be a controversial change (but you never know). Of course, you'd really want to use a URN for that, which is what a public ID is (and can be syntactically if you don't require formal public IDs). It's not really a question of registering FPIs, it's a question of making it clear what the abstract type is *to a human observer*. From a code perspective, either all you care about is the architectural declarations (so you can validate with respect to them), or you have the FPI hard-coded into a table of architectures that you understand. The most you have to do is implement the normalization rules for minimum literals (i.e., squeeze out non-significant white space). > > As I understand it, these PIs are *permitted* in XML (any PI is > permitted) > but they are given no special importance and implementers are not > required > to support them. So XML - as it stands today - has no mechanism for > requiring this to be implemented or interpreted. It could by using this mechanism as the basis for solving the name-space proposal. Note that XML doesn't have much in the way of syntax choices--it can't add a new declaration unless SGML does as well (which seems likely as part of the revision, but that's a ways off still). You can't use element attributes because that imposes on the document's private name space. So that only leaves notations and PIs. Notations are out because XML doesn't provide data attributes (which you need to do the configuration of the architecture use), so that leaves PIs. Thus, whatever you come up with will look very much like the PI defined in N1957 (the proposed HyTime amendment). Besides, talking about "required to support" is meaningless because it's not a syntactic issue--it's a semantic processing issue and you can never require semantic processing in a syntactic spec. You can require it in a semantic spec, such as HyTime or DSSSL or XML Link, but not in XML Lang. Or said another way, even if you make the true document type painfully clear to me, I am still free to ignore that information during processing. If the facility has value, systems will support it. Note also that in the simple case, where the document could use the architectural DTD as its own if it cared to, the mapping can be completely automatic (by the rules of default architectural mapping). In other words, if my architecture defines an element called "foo" and my document, derived from that architecture, has an element called "foo", then my foo is taken to be the architectural foo unless you tell me otherwise, without the need to explicitly map it. Thus, any document with an explicit DTD can use that same DTD as an architecture without changing the instance. In other words, I can go from this: <?XML 1.0 ?> <!DOCTYPE Foo SYSTEM "foo.dtd" > <foo/> To this: <?XML 1.0?> <?IS10744:arch name="foo" dtd-systemid="foo.dtd"?> <foo/> With exactly the same processing effect, except that no validating XML processor is *required* to process the declarations (but it can if it wants to, after XML Lang-required validation is done). This solves the problem of wanting to limit declarations to external subsets: you make the declarations architectural DTDs. The authors of individual documents can't modify the architectural DTD and any local declarations don't affect it (only the local mapping to the architecture), so architecture-based processors can be confident in only worrying only about the element types and attributes defined in the architectural DTD--they simply ignore anything in the base document that isn't architectural (that is, that isn't mapped to something in the architecture). This solves the problem that RDF is seeing, where they want to be able to disallow declarations in RDF documents but still have some formal specifications somewhere, without imposing the burdent of declaration awareness on all RDF-aware processors. With this approach they can do that. Here's one more trick. Say in your architecture you define your element type and attribute names using colons. For example, consider this simple architectural DTD: <!-- My simple architecture --> <!ELEMENT kimber:para (#PCDATA) > <!-- End of architectural DTD --> And this one: <!-- Another simple architecture --> <!ELEMENT woods:para (#PCDATA) > <!-- End of architectural DTD --> And this document derived from it: <?XML 1.0?> <?IS10744:arch name="kimber" dtd-systemid="kimber.dtd" ?> <?IS10744:arch name="woods" dtd-systemid="woods.dtd" ?> <foo> <kimber:para>This is a kimber paragraph</kimber:para> <para>This is not a kimber paragraph</para> <woods:para>This is a woods paragraph</woods:para> </foo> This looks just like all the colonized name proposals, but it's simply taking advantage of the automatic name mapping of architectures: the name "kimber:para" matches the name "kimber:para" in the kimber.dtd. Of course, the down side that if you want to map an element to two forms, you have some redundancy: <kimber:para woods="woods:para">This is both a kimber and woods para </kimber:para> But you can't have everything--at least you can *do* multiple mappings. You could also provide two different versions of the architectural DTD: one with colons and one without. You'd use the colonized one for the architecture you use the most and the non-colonized version for the others. The architecture definition document would explain the correlation between colonized and non-colonized versions of architectural elements for the benefit of implementors. Cheers, Eliot xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format