[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Lotsa laughs
John Cowan wrote: > > Lisa Rein wrote: > > > As far as your references to specifics on the BizTalk site go, I am > > still unable to get to those files without using IE5 - which I will get > > to eventually I suppose when I build up enough microsoft site-specific > > tasks to do so (how i've been handling the MS site for some time now > > since it seems the company has decided to require its own browser for a > > readible version of its site's content). > > That problem arises because part of the content of biztalk.org is > expressed using non-compliant HTML. It has nothing to do with > XML compliance. I never said it had anything to do with XML-compliance! It had to do with my using having to use a browser I only keep around for testing just to view the contents of a single site. (And I don't have version 4 anymore, unfortunately, since 5 wrote over it when i installed it -- without asking I might add). I was explaining why I was not responding to the comments Didier had made regarding specific documents on the biztalk site. I will now have to parse the documents for myself to see if they are xml-compliant or not, which is what I should have done in the first place...i guess... before making my statement one way or the other :-) > > > But let's just say for the sake of argument that the examples on the > > site were well-formed XML -- my question is this: Just because the > > DOCUMENT examples they show are well-formed XML, isn't it the SCHEMAS > > that would be validating those documents that would be "breaking" the > > current implementations? > > That's absurd. You might as well say that SMIL "breaks" XML because > it imposes additional restrictions. No, an XML-1.0-compliant parser > can't tell you whether a given document is SMIL. Why should it > be able to? As long as SMIL documents are well-formed XML (they are), > there is no problem. Well, that's what I was asking. Thanks. > > > Also, on a less technical, more practical note: Why would anyone want to > > put time into using the BizTalk schemas if they know are going to just > > have to redo them again when Microsoft, in good faith, changes the > > BizTalk schemas over to the W3C's Schema syntax? > > Distinguish between the syntax of Biztalk documents themselves, > and the syntax used to express the schemas that describe them. See that was exactly the point I was trying to make. So the clarification here (and correct me, please, if I'm wrong because I want to clear this up once and for all in my own mind) - is that, officially, if the syntax of "the BizTalk DOCUMENTS themselves" *IS* XML v 1.0 complaint (in the sense that it is well-formed and therefore parseable) even though the syntax used to express the schemas that describe them *ISN'T* XML-compliant? -- that it still counts as an XML-compliant XML application? Okay then. I thought that an XML v. 1.0-compliant application needed to be definable using a DTD (at this point) -- even if you didn't necessarily write one up for it -- that it *should* be possible to do so for any XML v 1.0-compliant application syntax. (like SMIL etc.) Is this NOT correct? > > > It was my understanding that, at this time, > > any schema syntax-based validation-mechanism, by definition, does not > > conform to the XML v. 1.0 Recommendation. Is this not true? > > The XML 1.0 Rec does not *prescribe* any validation mechanism other > than DTDs. Applications can, should, and must require validation > above what DTD-validation provides. can, should, and must require? according to whom? > > > Said another way: Since a currently-implemented, XML v. 1.0-compliant > > validating parser would not be able to use a BizTalk schema to validate > > documents (since BizTalk schemas use syntax that is not specified in the > > version 1.0 Recommendation), wouldn't such an existing XML v. > > 1.0-compliant parser implementation "break" as a result, unless its > > creators had also implemented whatever additional, non-standard (and > > therefore proprietary) software that BizTalk requires? > > "Nonstandard" does not mean proprietary. SAX is not a standard, > but it is hardly proprietary. > we've been through this already, haven't we? Nonstandard DOES mean proprietary, for lack of a better term. Software is one OR the other, and then the variations go FROM there. Although proprietary standards can still be freely available -- An "open, freely available, proprietary standard" would then mean that a spec is available for anyone to implement (which isn't true yet in the case of biztalk) - like the way the source code of SAX's libraries is available to anyone. or as Chris Lilley defined it: "Freely available in the sense you can download it and check that everything is actually documented and that it isn't missing some key component. And proprietary in the sense that one company controls the spec and can alter it whenever they see fit." In that sense David Megginson is the one "company". In BizTalk's case, it would be MS - if the process and the specs were indeed to be made public. > > Wouldn't a more "compliant" BizTalk strategy be to have BizTalk using > > DTDs for now, > > Biztalk restrictions may not be expressible using DTDs, which would > not be a deficiency. They may and they may not. No one knows for sure but microsoft. (and really, per their own docs, maybe they don't even know at this point) The rules that specify RDF aren't specifiable > by a DTD either. I really don't want to get into this discussion that can only immediately go over my head, but I'll go ahead and say that: 1) I thought on this very list the consensus was that, sometimes, RDF document syntax CAN be specified using a DTD (or is that different from saying that, sometimes, a DTD could be created for validating RDF documents?) 2) Remember, RDF does not necessarily HAVE to be expressed using XML. It is only one, optional syntax, officially (one of its downsides, yes in terms of interoperability between implementations?), while BizTalk is (in theory) an application of XML. Period. > > > That way, developers wouldn't have to choose one > > schema syntax over another (and at the expense of being incompatible > > with everything else) because the schema syntaxes would all be > > compatible - with each other AND early implementations that used the > > BizTalk DTDs for validation. > > As long as the W3C-compliant schemas and the Microsoft schemas have > the same meaning, one may freely create Biztalk-compliant documents > without fear that they will change meanings. What do you mean "have the same meaning"? Do you mean "as long as they are in compliance with each other?" I think we are saying the same thing. (I was saying that as long as Microsoft schemas are in compliance with the W3C's schema syntax. Ultimately MS "should" defer to the other, not the other way around...) > > > Why doesn't MS use the closest thing it can to the W3C Schema syntax for > > now, if it can't wait --rather than an undefined mishmash of two W3C > > member submissions and one unfinished white paper from almost year ago? > > Maybe they don't understand the current Schema draft yet, not to mention > it is imcomplete as of now. Exactly my point though - since BizTalk is obviously incomplete now as well, and since both things won't be done 'till 3rd quarter 99 anyway -- why not develop them in conjunction with each other. Or MS could just wait until the Schema syntax is ready, so as not to fragment the market ahead of time. (oops! i forgot that that was the whole objective :-) lisa 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/ and on CD-ROM/ISBN 981-02-3594-1 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
|