Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: nested namespaces
 On Sun, Dec 15, 2002 at 09:14:50PM -0500, Simon St.Laurent wrote: > I'm not entirely sure from reading the draft what it is that you're > proposing or that a media type (as opposed to a media feature[1], for > instance) is the right way to go about it. My summary of the document > would suggest that content of type application/xmld should be processed > on a namespace-URIs-first basis, but it's not clear to me what > (especially in the absence of a schema or perhaps better a RDDL > document) should be done when unknown namespaces are encountered. Well, that's a large part of what the draft is about, though I know it's still far from complete. Also, for several reasons, I want to avoid having to look up schema or similar; one big one being that a document should have a standalone meaning, even if you don't know how to extract all of it. > I think that document is an interesting start, but it's not clear to me > that "dispatch" is the right paradigm for namespace-based processing. > Dispatch makes sense in the context of, say, an XHTML document with > embedded XForms and SVG and using plug-in-like mechanisms for the > handling. I'm not sure it makes the same kind of sense as a general > approach to handling namespaces and XML - but I'll confess that I'm not > sure what a general approach might look like. I think it's fairly general (well, if it were complete 8-), but not completely so. Like I said, I was *aiming* for an 80/20 solution. > <record xmlns="http://simonstl.com/ns/record" > xmlns:str="http://www.w3.org/TR/xmlschema-2/#string" > xmlns:date="http://www.w3.org/TR/xmlschema-2/#date" > xmlns:int="http://www.w3.org/TR/xmlschema-2/#int" > > > <str:firstName>Simon</str:firstName> > <date:birthdate>1970-11-25</date:birthdate> > <int:age>32</int:age> > </record> > > In this case, the "collection of names" is a collection of names that > happen to contain strings, dates, or integers, not a collection that > was precisely connected to a vocabulary. Right, which is why I consider that broken. I haven't seen it before anyhow, so I don't know that it's worth considering for an 80/20 solution. > Also, local names have real power - href and id are two very common > local names used in multiple namespaces, for instance. (You acknowledge > that in the draft.) There are real cases where that local name may in > fact be more important to processing (link and bastardized ID hunting) > than the namespace that happens to be applied to it. This kind of > thing keeps coming up in various contexts, and I doubt it will > disappear soon. Hmm. I'd have to think about it. > I wish I saw a simple 80/20 here, but I really don't, especially if > elements using unknown "visiting" namespaces contain content in "known" > namespaces. That case depends on two things; what it means to each namespace, that another namespace is contained within the given elements. The former is a known quantity, because its the known namespace. The latter, without any indication to the contrary, should mean that portion of the document is not processable (which may be ok, depending upon the semantics of the innermost container of the known namespace). By "indication", I mean that the producer of the compound document could provide hints to aid in partial processing. A mandatory extension declaration would be one kind of hint. But another may be an indication of the type of container, such as if it's a sequence, a set of alternatives, a bag, etc.. (like rdf:Container). Perhaps that might be helpful in processing it, not sure. Haven't really thought that through, though I probably should if it's gonna be 80/20. > [1] - http://simonstl.com/ietf/draft-stlaurent-feature-xmlns-03.txt is a > media feature which identifies the namespaces used in a document rather > than specifying their processing, but a media feature saying something > like "this document expects namespace dispatching" might make sense and > be easily integrated with a wide variety of +xml types. Yes, I should have considered that option in the binding section. But I feel that a new media type is still the best way to go, at least at this point in time. If enough people feel this is important, I'd be happy to work on this again. My hunch is that there *is* an 80/20 solution here, but it ain't gonna be easy. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis 
|
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
|
|||||||||
