Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Important XML announcements [from James Anderson]
 >Return-Path: <James.Anderson@m...> > >greetings, >it is nice to see that the discussion on namespaces has reached wd status. > >i have four remarks on the document: > >I: the discussion regarding ambiguous names is too brief. > >in particular, it is not clear (given the restriction on "no fragments" in the >namespace pi uri, how the multiple names spaces would be defined with reference >to a single, integral schema. as i followed the document, '.'-qualified names >appear for the first time at that point; i couln't figure out how they are >expressed or interpreted. > >II: the discussion of the scope of the invocation of a namespace should be more >thorough. > >i recall this issue being discussed at greater length in other documents on xml >namespaces and miss it here. in particular, that the scope extends over the >content of an opening tag, but not over the dependant elements, requires better >treatment. the interpretation of unqualified attribute names is, for example, >specified, but that for unqualified tag names was not to be found at the >analogous location in the discussion. > >this distinction is unfortunate from the point of view of applying the standard, >as is that between names for tags and those for entities. more discussion is >required here. a more consistent semantic is no harder to implement, easier to >understand, and more compact in expression. > >together with the restriction that entity names are always unqualified, it leads >me to the belief that i won't be able to make cross-schema references to entity >definitions. is that true? is that intended? > >III: w.r.t item D. > >> D. ... Given the extraordinary depth of the problem that the >> specification begins to address, the importance of solving that >> problem correctly, the lack of implementation experience in this area, >> ... > >i note that this proposal (as did an earlier one) describes much the same >mechanism as the package mechanism in common lisp (minus >export/import/inter-package-inheritance). there is much useful experience to be >drawn on there. > >> Persons wishing to make useful contributions to the public review of >> the draft should confine their comments to pointing out broken places >> in those mechanisms that the draft provides rather than suggesting >> additional ones. > >the implementation of namespaces on the basis of packages in a cl-based >implementation of an xml processor was quite straightforward. it suggests that >the proposed namespace mechanism (though not "broken") could be made more >complete, if it were kept simpler and uniform: > >1. all unqualified tokens are interned into the package bound to the variable >*package*. qualified tokens are interned into the package named by the >qualification. this package must exist. >2. *package* is rebound at the start of each element entity to the package into >which the element tag name has been interned. after the close tag for an element >entity, *package* is returned to its previous binding. the qualification of the >close tag could be optional, but i have found it to be a useful constraint. >3. external entities are read, with the exceptions of dtd entities, according to >the current *package* binding. dtd entites are read as follows: > a. a namespace pi creates a package with the specified name (the 'prefix' >attribute from the spec) and rebinds *package* to that value while reading the >dtd. > b a doctype entity creates a package with the same name as the document type, >and sets *package* to that value. the value thereby becomes the default package >for the external dtd, for an internal dtd if one is present, and for the root >document element. when reading a dtd, i've restricted all entity definition >names to be unqualified, but that doesn't need to be. >4. any defined package inherits from the "XML" package, in which all standard >tokens interned and from which they are exported. > >this mechanism makes references to all elements (including entities) of a given >dtd very simple. >it permits cross-dtd references. >it is easy to implement and to understand because it is uniform. >i have yet to see a <em>naming</em> example from the various documents on >namespaces which could not be expressed given these semantics. no, it doesn't >address the <em>architectural</em> examples, but then it's orthogonal to them. > > >IV: the section on universal names is too brief. > >i understand, that such information would be a necessary in order to identify >the origin of a name. what i don't understand is why one would need to do this. >when i specify that tokens belong in different packages, it's because i want >them to be different. the overhead of managing a directly available universal >namespace seems at first reflection to be high for something i'd "never" do, >but, i admit, i may well be shortsighted here. in my present implementation, >the information is available indirectly through the package, to the dtd, to the >dtd's uri, but i wouldn't call that a universal namespace. >an example of the intended purpose would be very useful here - and necessary in >order to judge how to best implement it. > >bye for now, >james anderson > > > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg 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
|
|||||||||
